[openstack-dev] [tricircle] weekly meeting of Dec.23

[joehuang]

Hi,

A weekly meeting will be held today at the UTC1300 at #openstack-meeting before 
the X’Mas and New Year holiday.

Agenda:
Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo
Discussion of stateless design.


Best Regards
Chaoyi Huang ( Joe Huang )

From: joehuang
Sent: Wednesday, December 16, 2015 2:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] weekly meeting of Dec.16

Hi,

Let’s have regular meeting today starting UTC1300 at #openstack-meeting

Agenda:
Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo
Discussion of stateless design.


Best Regards
Chaoyi Huang ( Joe Huang )

From: joehuang [mailto:joehu...@huawei.com]
Sent: Tuesday, December 08, 2015 1:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle]Stateless design proposal for Tricircle 
project

Hi,

Managing multiple instances of OpenStack is a headache.  Each OpenStack 
instance is individual silo, with its separate resources, networks, images, etc.

Tricircle, the project aiming to address this headache, a Top (aka cascading) 
minimalist "OpenStack instance" will manages multiple Bottom (aka cascaded) 
OpenStack instances. The top will expose OpenStack API to embrace all 
eco-system built upon OpenStack API. This model and its value has been verified 
in several production clouds.

Now one stateless design for the Tricircle, the top minimalist "OpenStack 
instance",  is just proposed in the doc [1]:

The stateless design introduce several components, and fully decoupled with 
OpenStack services like Nova, Cinder, and the Tricircle plugin will work just 
like OVN, ODL plugin in Neutron project, the design also try to remove the uuid 
mapping, status synchronization challenges.

•  Admin API
manage sites(bottom OpenStack instances) and availability zone mapping
retrieve object uuid routing
expose api for maintenance
•  Nova API-GW
an standalone web service to receive all nova api request, and routing the 
request to regarding bottom OpenStack according to Availability Zone ( during 
creation ) or resource id ( during operation and query ).
work as stateless service, and could run with processes distributed in 
multi-hosts.
•  Cinder API-GW
an standalone web service to receive all cinder api request, and routing the 
request to regarding bottom OpenStack according to Availability Zone ( during 
creation ) or resource id ( during operation and query ).
work as stateless service, and could run with processes distributed in 
multi-hosts.
•  XJob
receive and process cross OpenStack functionalities and other async. jobs from 
message bus for example, when booting a VM for the first time for the project, 
router, security group rule, FIP and other resources may have not already been 
created in the bottom site, but it’s required. Not like network, security 
group, ssh key etc resources they must be created before a VM booting, these 
resources could be created in async.way to accelerate response for the first VM 
booting request
cross OpenStack networking also will be done in async. jobs
Any of Admin API, Nova API-GW, Cinder API-GW, Neutron Tricircle plugin could 
send an async. job to XJob through message bus with RPC API provided by XJob
•  Neutron Tricircle plugin
Just like OVN, ODL Neutron plugin, the tricircle plugin serve for multi-site 
networking purpose, including interaction with DCI SDN controller, will use ML2 
mechanism driver interface to call DCI SDN controller, especially for cross 
OpenStack provider multi-segment L2 networking.
•  DB
Tricircle can have its own database to store sites, fake nodes, availability 
zone mapping, jobs, resource routing table

A plan to do PoC for this idea is working on the experiment branch of Tricircle 
[2][4], once the result give us positive feedback, the work will be moved to 
the master branch.

Welcome to join the adventure, contribute your power in the review, design  
writing source code, maintaining infrastructure, testing, bug fix, the weekly 
meeting[3]..., all work just starts[4].

[1] design doc: 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g
[2] Stateless design branch: 
https://github.com/openstack/tricircle/tree/experiment
[3] weekly meeting: #openstack-meeting on every Wednesday starting from UTC 
13:00
[4] To do list is in the etherpad: 
https://etherpad.openstack.org/p/TricircleToDo

Best Regards
Chaoyi Huang ( Joe Huang )

From: joehuang
Sent: Wednesday, December 02, 2015 2:37 PM
To: 'Zhipeng Huang'; OpenStack Development Mailing List (not for usage 
questions); caizhiyuan (A); Irena Berezovsky; Orran Krieger; Mohammad 
Badruzzaman; 홍석찬
Subject: [openstack-dev][tricircle] weekly meeting of Dec.2

Hi,

Let’s have regular meeting today starting UTC1300 at #openstack-meeting.

The networking proposal is updated in the document, and a proposal for 
stateless PoC also was 

Re: [openstack-dev] [neutron] How to make deb and rpm packages for a networking-* project?

[P. Ramanjaneya Reddy]

Hi fawad,

I'm trying to understand how deb and rpm generate works for plumgrind.

rpm generation fine, but for deb has some problem. Can help how to solve
it, so that it would be helpful for my project as well

https://review.openstack.org/#/c/248239

networking_plumgrid-2015.2.1/packaging/rpm-packaging/networking-plumgrid.spec
networking_plumgrid-2015.2.1/packaging/rpm-packaging/rpm-packaging.sh
networking_plumgrid-2015.2.1/.testr.conf
*dch: fatal error at line 605:*
*File debian/changelog already exists!*
root1@root1-ThinkPad-T440p
:~/openstack-/openstack/networking-plumgrid/packaging/debian-packaging$



Writing networking_plumgrid-2015.2.1/setup.cfg
Creating tar archive
removing 'networking_plumgrid-2015.2.1' (and everything under it)
Wrote: /home/root1/rpmbuild/SRPMS/networking_plumgrid-2015.2.1-1.0.src.rpm
root1@root1-ThinkPad-T440p
:~/openstack-/openstack/networking-plumgrid/packaging/rpm-packaging$

Thanks & Regards,
Ramanji.

On Tue, Dec 22, 2015 at 11:52 AM, Fawad Khaliq  wrote:

> There is one example [1] in review and may be incomplete but might help.
> It only adds the scripts to build. Publishing part is different.
>
> [1] https://review.openstack.org/#/c/248239/
>
> Fawad Khaliq
>
>
> On Tue, Dec 22, 2015 at 11:15 AM, P. Ramanjaneya Reddy <
> ramanji...@gmail.com> wrote:
>
>>
>> Hi All,
>>
>> Can someone help on..
>> How to make rpm and deb packages for a networking-* project?
>>
>> Thanks & Regards,
>> Ramanji.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Merge Freeze for cutting stable/8.0 branch

[Bogdan Dobrelya]

On 23.12.2015 08:48, Aleksandra Fedorova wrote:
> Hi Fuelers,

Hello.
I'm sorry I've missed this and have made several merges accumulated
since the ~24h *disaster* of red BVT/smoke builds. There were many
medium bugfixes awaiting for the green light from our BVT. Would've been
very sad to miss them due to the technical issues...

> 
> SCF has been declared [1] and we start creating stable/8.0 branch in
> all projects.
> 
> Please don't merge anything both to master and to stable/8.0 until we
> verify Infra and CI readiness.
> 
> List of projects affected:
> 
>   fuel-main
>   fuel-agent
>   fuel-astute
>   fuel-library
>   fuel-menu
>   fuel-ostf
>   fuel-qa
>   fuel-upgrade
>   fuel-web
>   shotgun
>   python-fuelclient
>   network-checker
>   fuel-nailgun-agent
>   fuel-mirror
> 
> Use #fuel-infra or #fuel-dev IRC channels for questions.
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082939.html
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Bogdan Dobrelya]

On 22.12.2015 21:12, Yuriy Taraday wrote:
> Hello, everybody.
> 
> It's a week old thread and I should've jumped in earlier. Better late
> than never.
> 
> On Wed, Dec 16, 2015 at 2:04 AM Dmitriy Shulyak  > wrote:
> 
> Hello folks,
> 
> This topic is about configuration storage which will connect data
> sources (nailgun/bareon/others) and orchestration. And right now we
> are developing two projects that will overlap a bit.
> 
> I understand there is not enough context to dive into this thread
> right away, but i will appreciate if those people, who participated
> in design, will add their opinions/clarifications on this matter.
> 
> 
> Let's try to add more context here. I see a lot of confusion around this
> matter. I think most of it comes from not having a single complete
> source of data about both approaches. I'll try to summarize the problem
> and outline proposed solutions as well as state of implementation for those.
> 
> == The problems. ==
> 
> Currently we have 2 main problems in question:
> 1. How to store data in Fuel so that it can come from different sources
> and be consumed by different pieces of software.
> 2. How to integrate Solar with Fuel and allow it to consume data
> provided by Nailgun (currently) or whatever else (if we get #1 implemented).

IIUC, that exposes Config Service to Solar as a "proxy" data source
among with other external sources like Nailgun, LDAP, IPAM and so on.
But there is support of external data sources on the Solar radar as
well. Developing "data resources" with "data processors" in Solar in
parallel with the Config Service doing literally the same -but as a
proxy data access layer- would bring major duplication of efforts, which
is not good. Instead, we should re-think of a "flat model" with no data
proxies and using Solar framework from the very beginning, IMHO.

I suggest to address this issue ASAP.

> 
> I was assigned (driven, actually) to look at the problem #1, and so with
> a start of a number of ideas from Oleg and others from my team and after
> some discussion with other people involved in Fuel architecture, I've
> finalized the scope and outlined architecture of the service that we
> would need to solve it in [0]. I didn't mean to step on anyone's toes,
> but later I was shown that the similar issue is being solved by SolarDB
> initiative that is being developed in the scope of integration between
> Solar and Fuel.
> 
> == The solutions. ==
> 
> = Config Service =
> 
> (because ConfigDB became an overused and ill-defined term)
> 
> Config Service is thought as a way to link Nailgun (and other sources in
> the future) to deployment tasks (and other consumers in the future) in a
> consistent and verifiable way. Someone lets the service know about the
> structure of the data that components provide and the structure of the
> data that other components consume thus declaring internal data flow
> between sources and consumers of data. Then for every environment
> Nailgun (for now - it can be other service, it can be changed to pull
> model later) feeds all necessary data into the service, triggers
> deployment tasks that consume data from the service the way that is more
> suitable for them. If we need to feed this data into some external
> service (Puppet master, for example), we're free to do so as long as we
> define data structure that a consumer expects.
> 
> = SolarDB =
> 
> (mainly based on [1] and presentations seen earlier, please correct me
> if smth wrong)
> 
> SolarDB includes active component: Data Processors (DPs). DPs fetch data
> from wherever they're intended to (Nailgun for starters, any other
> source in the future) and store them as Solar's Data Resorces (DRs). DRs
> are then translated to concrete data for other Solar's Resources
> (Executable Resources, ERs), this data is preprocessed by Policy Engine
> and converted to a set of calls to mutators that change ERs data in
> Solar's internal database in a way that lets Solar decide what should be
> done to change actual state of the environment.
> 
> == State of implementations ==
> 
> = Config Service =
> 
> I plan to show a PoC for Config Service integration before the end of
> this year. Coding of the service itself is almost at finish line at [2],
> integration with Nailgun and Astute/Puppet will take most of the
> remaining time.
> 
> = SolarDB =
> 
> PoC with Data Processors and Data Resources happened with simple cluster
> architecture (I don't know the date here). Policy Engine is in early
> stages of development.
> 
> == Main differences ==
> 
> I'll try to list main differences along with what seems for me pros and
> cons for both sides (major points taken from original Dmitriy's email).
> 
> 1. Config Service (CS) is initially planned as a passive element of
> integration while SolarDB (SD) have DPs that actively fetch data from
> the sources.
> 
> CS+: simpler implementation, can get PoC 

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Steven Hardy]

On Tue, Dec 22, 2015 at 03:36:02PM +, Dougal Matthews wrote:
>Hi all,
> 
>This topic came up in the 2015-12-15 meeting[1], and again briefly today.
>After working with the code that came out of the deployment library
>spec[2] I
>had some concerns with how we are storing the templates.
> 
>Simply put, when we are dealing with 100+ files from
>tripleo-heat-templates
>how can we ensure consistency in Swift without any atomicity or
>transactions.
>I think this is best explained with a couple of examples.
> 
> - When we create a new deployment plan (upload all the templates to
>swift)
>   how do we handle the case where there is an error? For example, if we
>are
>   uploading 10 files - what do we do if the 5th one fails for some
>reason?
>   There is a patch to do a manual rollback[3], but I have concerns
>about
>   doing this in Python. If Swift is completely inaccessible for a short
>   period the rollback wont work either.

How does using a different data store help fix this error path?

Regardless of the Swift/DB/Git choice, you have to detect something failed,
and mark the plan as in a failed state.

> - When deploying to Heat, we need to download all the YAML files from
>Swift.
>   This can take a couple of seconds. What happens if somebody starts to
>   upload a new version of the plan in the middle? We could end up
>trying to
>   deploy half old and half new files. We wouldn't have a consistent
>view of
>   the database.

If this happens, the API design is wrong - we should have a plan reference
a unique identifier, including a version (e.g through swift versioned
objects, git tags/branches or whatever), then on deployment heat should
download exactly one version of those artefacts (e.g via a swift tempurl or
a git URL, or whatever).

FYI heatclient already supports downloading template objects directly from
swift, and heat/heatclient already support downloading from http URLs, so
all we have to do AFAICS is generate a URL pointing to a consistent
version of the templates.

>We had a few suggestions in the meeting:
> 
> - Add a locking mechanism. I would be concerned about deadlocks or
>having to
>   lock for the full duration of a deploy.

I think we need to create a new version of a plan every time it's modified,
then on deployment the concern around locking is much reduced, or even
eliminated?

> - Store the files in a tarball (so we only deal with one file). I think
>we
>   could still hit issues with multiple operations unless we guarantee
>that
>   only one instance of the API is ever running.
> 
>I think these could potentially be made to work, but at this point are we
>using the best tool for the job?
> 
>For alternatives, I see a can think of a couple of options:
> 
>- Use a database, like we did for Tuskar and most OpenStack API's do.

Storing template files in a database with Tuskar was a mistake - we should
*not* do that again IMO - it was a very opaque interface and caused a lot
of confusion in use.

Storing code (in this case yaml files) in some sort of versioned repository
is *such* a solved problem - it'll be total wheel-reinventing if we
implement template revision control inside a bespoke DB IMHO.

I think swift is probably a workable solution (using versioning and
tempurl's), but we should really consider making the template store
pluggable, as having the API backed by an (operator visible) git repo is
likely to be a nicer and more familiar solution.

The question around validation data I'm less clear on - we already store
discovery data in swift, which seems to work OK - how is the validation
data different, in that it warrants a bespoke DB data store?

Steve

__
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] [tricircle] meeting minutes of Dec.23

[joehuang]

Hi,



Thanks team's hard working, a great step for the stateless design.



Meeting minutes is attched here, the phase 1 of stateless design is almost 
done, and now we can boot a server with flavor, image, az and network through 
Tricircle to bottom cascaded OpenStack ( an bottom cascaded OpenStack is called 
a Pod : ) )



  1.  The basic function of nova api gateway is done and code has been merged 
(joehuang,
 13:08:12)
  2.  https://etherpad.openstack.org/p/TricircleToDo 
(joehuang,
 13:11:24)
  3.  ACTION: update the design doc about the dhcp part 
(joehuang,
 13:11:40)
  4.  ACTION: guide to play tricircle with devstack 
(joehuang,
 13:15:22)
  5.  the design doc is updated with the region/az/pod/dc/top/bottom concept 
and data model 
(joehuang,
 13:17:36)
  6.  OpenStack Austin Summit CFP started today 
(zhipeng,
 13:20:40)

http://eavesdrop.openstack.org/meetings/tricircle/2015/tricircle.2015-12-23-13.04.html
http://eavesdrop.openstack.org/meetings/tricircle/2015/tricircle.2015-12-23-13.04.txt
http://eavesdrop.openstack.org/meetings/tricircle/2015/tricircle.2015-12-23-13.04.log.html

Merry X'Mas and Happy New Year.

Best Regards
Chaoyi Huang ( joehuang )

From: joehuang
Sent: 23 December 2015 17:34
To: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] weekly meeting of Dec.23

Hi,

A weekly meeting will be held today at the UTC1300 at #openstack-meeting before 
the X’Mas and New Year holiday.

Agenda:
Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo
Discussion of stateless design.


Best Regards
Chaoyi Huang ( Joe Huang )

From: joehuang
Sent: Wednesday, December 16, 2015 2:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] weekly meeting of Dec.16

Hi,

Let’s have regular meeting today starting UTC1300 at #openstack-meeting

Agenda:
Progress of To-do list: https://etherpad.openstack.org/p/TricircleToDo
Discussion of stateless design.


Best Regards
Chaoyi Huang ( Joe Huang )

From: joehuang [mailto:joehu...@huawei.com]
Sent: Tuesday, December 08, 2015 1:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle]Stateless design proposal for Tricircle 
project

Hi,

Managing multiple instances of OpenStack is a headache.  Each OpenStack 
instance is individual silo, with its separate resources, networks, images, etc.

Tricircle, the project aiming to address this headache, a Top (aka cascading) 
minimalist "OpenStack instance" will manages multiple Bottom (aka cascaded) 
OpenStack instances. The top will expose OpenStack API to embrace all 
eco-system built upon OpenStack API. This model and its value has been verified 
in several production clouds.

Now one stateless design for the Tricircle, the top minimalist "OpenStack 
instance",  is just proposed in the doc [1]:

The stateless design introduce several components, and fully decoupled with 
OpenStack services like Nova, Cinder, and the Tricircle plugin will work just 
like OVN, ODL plugin in Neutron project, the design also try to remove the uuid 
mapping, status synchronization challenges.

•  Admin API
manage sites(bottom OpenStack instances) and availability zone mapping
retrieve object uuid routing
expose api for maintenance
•  Nova API-GW
an standalone web service to receive all nova api request, and routing the 
request to regarding bottom OpenStack according to Availability Zone ( during 
creation ) or resource id ( during operation and query ).
work as stateless service, and could run with processes distributed in 
multi-hosts.
•  Cinder API-GW
an standalone web service to receive all cinder api request, and routing the 
request to regarding bottom OpenStack according to Availability Zone ( during 
creation ) or resource id ( during operation and query ).
work as stateless service, and could run with processes distributed in 
multi-hosts.
•  XJob
receive and process cross OpenStack functionalities and other async. jobs from 
message bus for example, when booting a VM for the first time for the project, 
router, security group rule, FIP and other resources may have not already been 
created in the bottom site, but it’s required. Not like network, security 
group, ssh key etc resources they must be created before a VM booting, these 

Re: [openstack-dev] [openstack][magnum]a problem about trust

[Hongbin Lu]

+1

Thanks Steven for pointing out the pitfall.

Best regards,
Hongbin

-Original Message-
From: Steven Hardy [mailto:sha...@redhat.com] 
Sent: December-23-15 3:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack][magnum]a problem about trust

On Tue, Dec 22, 2015 at 04:55:17PM +0800, 王华 wrote:
>Hi all,
>When we create a trust to a trustee with a role, the trustor must have
>this role. Here is a problem I meet in my bp [1]. I need to create a trust
>with a role, with the trust docker registry can access Swift to store
>images. But the trustor (the user who uses magnum) may not have the role.
>How can we address this problem?

FYI we had this exact same issue in Heat some time ago:

https://bugs.launchpad.net/heat/+bug/1376562

>There are two ways.
>1. Add the role to the trustor with the magnum admin user privilege. But
>when we need to delete the role, we can not know whether the role is added
>by magnum or is owned by the trustor.
>2. Let magnum trust the trustee with the role. We can assign the role to
>magnum before we start magnum.Â

As you'll see from the bug report above, neither of these solutions work, 
because you can't know at the point of delegation what roles may be needed in 
the future when impersonating the trustor.

So, having a special role which is always delegated (as you are proposing, and 
Heat used to do) doesn't work very well in environments where RBAC is actually 
used.

The solution we reached in Heat is to delegate all roles, as determined by 
keystone/authtoken, with the option for deployers to specify some specific role 
or list of roles if they have an RBAC scheme where the expected roles are 
predictable:

See https://review.openstack.org/128509 for the Heat solution.

HTH!

Steve

__
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] [Fuel] Nominate Artem Roma for fuel-ostf core

[Tatyana Leontovich]

Hi guys,
I'd like to nominate Artem Roma [0] for fuel-ostf core.

Artem  cares about fuel-ostf more then 2 years, always provide a great
reviews(always thorough and consistent and comes in time), extend unit
tests coverages and provide a lot of bug fixes and improvements there.

Please, vote for Artem!

http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf
__
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] Is Swift a good choice of database for the TripleO API?

[Steven Hardy]

On Wed, Dec 23, 2015 at 09:28:59AM -0600, Ben Nemec wrote:
> On 12/23/2015 03:19 AM, Dougal Matthews wrote:
> > 
> > 
> > On 22 December 2015 at 17:59, Ben Nemec  > > wrote:
> > 
> > Can we just do git like I've been suggesting all along? ;-)
> > 
> > More serious discussion inline. :-)
> > 
> > On 12/22/2015 09:36 AM, Dougal Matthews wrote:
> > > Hi all,
> > >
> > > This topic came up in the 2015-12-15 meeting[1], and again briefly
> > today.
> > > After working with the code that came out of the deployment library
> > > spec[2] I
> > > had some concerns with how we are storing the templates.
> > >
> > > Simply put, when we are dealing with 100+ files from
> > tripleo-heat-templates
> > > how can we ensure consistency in Swift without any atomicity or
> > > transactions.
> > > I think this is best explained with a couple of examples.
> > >
> > >  - When we create a new deployment plan (upload all the templates
> > to swift)
> > >how do we handle the case where there is an error? For example,
> > if we are
> > >uploading 10 files - what do we do if the 5th one fails for
> > some reason?
> > >There is a patch to do a manual rollback[3], but I have
> > concerns about
> > >doing this in Python. If Swift is completely inaccessible for a
> > short
> > >period the rollback wont work either.
> > >
> > >  - When deploying to Heat, we need to download all the YAML files from
> > > Swift.
> > >This can take a couple of seconds. What happens if somebody
> > starts to
> > >upload a new version of the plan in the middle? We could end up
> > trying to
> > >deploy half old and half new files. We wouldn't have a
> > consistent view of
> > >the database.
> > >
> > > We had a few suggestions in the meeting:
> > >
> > >  - Add a locking mechanism. I would be concerned about deadlocks or
> > > having to
> > >lock for the full duration of a deploy.
> > 
> > There should be no need to lock the plan for the entire deploy.  It's
> > not like we're re-reading the templates at the end of the deploy today.
> >  It's a one-shot read and then the plan could be unlocked, at least as
> > far as I know.
> > 
> > 
> > Good point. That would be holding the lock for longer than we need.
> >  
> > 
> > The only option where we wouldn't need locking at all is the
> > read-copy-update model Clint mentions, which might be a valid option as
> > well.  Whatever we do, there are going to be concurrency issues though.
> >  For example, what happens if two users try to make updates to the plan
> > at the same time?  If you don't either merge the changes or disallow one
> > of them completely then one user's changes might be lost.
> > 
> > TBH, this is further convincing me that we should just make this git
> > backed and let git handle the merging and conflict resolution (never
> > mind the fact that it gets us a well-understood version control system
> > for "free").  For updates that don't conflict with other changes, git
> > can merge them automatically, but for merge conflicts you just return a
> > rebase error to the user and make them resolve it.  I have a feeling
> > this is the behavior we'll converge on eventually anyway, and rather
> > than reimplement git, let's just use the real thing.
> > 
> > 
> > I'd be curious to hear more how you would go about doing this with git. I've
> > never automated git to this level, so I am concerned about what issues we
> > might hit.
> 
> TBH I haven't thought it through to that extent yet.  I'm mostly
> suggesting it because it seems like a fit for the template storage
> requirements - we know we want version control, we want to be able to
> merge changes from multiple sources, and we want some way to handle
> merge conflicts.  Git does all of this already.
> 
> That said, I'm not sure about everything here.  For example, how would
> you expose merge conflicts to the user?  I don't know that I would want
> to force a user to learn git in order to use TripleO (although that
> would be the devops-y thing to do), but maybe just passing them back the
> files with the merge conflict markers and having them resolve those
> locally and retry the update would work.  I'm not sure how that would
> map to the current version of the API though.  Do we provide any way to
> pass templates back to the user?  I feel like that was kind of a one-way
> street.

What part of the deployment API workflow could result in merge conflicts?

My understanding was that it's something like:

1. Take copy of reference templates tree
2. Introspect tempalates, expose required parameters so user can be
prompted for them
3. Create environment files(s) derived from the user input
4. Validate the 

[openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Andrey Sledzinskiy]

Hi guys,
I'd like to nominate Artem Panchenko [0] for fuel-qa core.

Artem has great technical expertise in fuel-qa and he developed a lot of
vital parts of framework. His first place in a number of commits is a good
proof of that.
His reviews are always thorough and consistent.
Please, vote for Artem!

[0]
http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa

-- 
Thanks,
Andrey Sledzinskiy
QA Engineer,
Mirantis, Kharkiv
__
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] [Glance] [Artifacts] [app-catalog] Proposed pre-holiday Artifacts virtual meetup.

[Nikhil Komawar]

Due to a urgent uncalled meeting for some of the folks we are postponing
the call to a later time. We will communicate as things progress.

For now, you should expect to find no one on the hangout link given.

On 12/21/15 11:31 PM, Nikhil Komawar wrote:
> I would like to close the poll now and call the meeting at 1530UTC on
> Wednesday 23rd December for around 90 mins.
>
> If there are more additions to the call please let me know by tomorrow
> (Tuesday Dec 22nd 2100UTC) to identify the need for a different
> communication platform. Else we will be using the hangout link given in
> the poll ( http://doodle.com/poll/adq4y5ppiy4hqcww ).
>
> Please find the tentative agenda proposed here (
> https://etherpad.openstack.org/p/mitaka-glare-preholiday-sync ). We may
> have more items closer to the meeting and you are encouraged to add sub
> topics as appropriate.
>
> Again, please let me know if you have concerns.
>
> On 12/20/15 10:49 PM, Nikhil Komawar wrote:
>> Hi all,
>>
>> Sorry to send this last minute; but as informally decided and having had
>> some momentum on Artifacts with a few decision items to be taken, it
>> would be nice to have a virtual sync before the holiday season begins.
>>
>> I have created a poll for the same. Please vote on the doodle as soon as
>> possible ( http://doodle.com/poll/adq4y5ppiy4hqcww ). Attached is the
>> hangout link for participation however, we may utilize other video
>> conference media if large number of participants show up. The meeting
>> time would be 60-90 minutes and is likely to happen either this Tuesday
>> or Wednesday (as shown on doodle) if poll is successful.
>>
>> Please let me know if anyone has concerns.
>>

-- 

Thanks,
Nikhil


__
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] [Fuel] Nominate Artem Roma for fuel-ostf core

[Aleksandr Didenko]

+1

On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy <
asledzins...@mirantis.com> wrote:

> +1
>
> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich <
> tleontov...@mirantis.com> wrote:
>
>> Hi guys,
>> I'd like to nominate Artem Roma [0] for fuel-ostf core.
>>
>> Artem  cares about fuel-ostf more then 2 years, always provide a great
>> reviews(always thorough and consistent and comes in time), extend unit
>> tests coverages and provide a lot of bug fixes and improvements there.
>>
>> Please, vote for Artem!
>>
>>
>> http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf
>>
>> __
>> 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
>>
>>
>
>
> --
> Thanks,
> Andrey Sledzinskiy
> QA Engineer,
> Mirantis, Kharkiv
>
> __
> 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] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 23 December 2015 at 12:01, Steven Hardy  wrote:

> On Tue, Dec 22, 2015 at 03:36:02PM +, Dougal Matthews wrote:
> >Hi all,
> >
> >This topic came up in the 2015-12-15 meeting[1], and again briefly
> today.
> >After working with the code that came out of the deployment library
> >spec[2] I
> >had some concerns with how we are storing the templates.
> >
> >Simply put, when we are dealing with 100+ files from
> >tripleo-heat-templates
> >how can we ensure consistency in Swift without any atomicity or
> >transactions.
> >I think this is best explained with a couple of examples.
> >
> >Â - When we create a new deployment plan (upload all the templates to
> >swift)
> >Â Â  how do we handle the case where there is an error? For example,
> if we
> >are
> >Â Â  uploading 10 files - what do we do if the 5th one fails for some
> >reason?
> >Â Â  There is a patch to do a manual rollback[3], but I have concerns
> >about
> >Â Â  doing this in Python. If Swift is completely inaccessible for a
> short
> >Â Â  period the rollback wont work either.
>
> How does using a different data store help fix this error path?
>
> Regardless of the Swift/DB/Git choice, you have to detect something failed,
> and mark the plan as in a failed state.
>

If your connection to a database such as postrges drops mid-transaction it
will be rolled back. So for a networking issue it would help. Granted, I am
not
sure exactly what happens if somebody pulls the plug on the database, but
then you probably have bigger issues. Failed network requests seem
relatively
common.



> >Â - When deploying to Heat, we need to download all the YAML files
> from
> >Swift.
> >Â Â  This can take a couple of seconds. What happens if somebody
> starts to
> >Â Â  upload a new version of the plan in the middle? We could end up
> >trying to
> >Â Â  deploy half old and half new files. We wouldn't have a consistent
> >view of
> >Â Â  the database.
>
> If this happens, the API design is wrong - we should have a plan reference
> a unique identifier, including a version (e.g through swift versioned
> objects, git tags/branches or whatever), then on deployment heat should
> download exactly one version of those artefacts (e.g via a swift tempurl or
> a git URL, or whatever).
>

Sure, this sounds like a valid point against the design of both the storage
spec
that was merged and the API spec that is up for review.


>
> FYI heatclient already supports downloading template objects directly from
> swift, and heat/heatclient already support downloading from http URLs, so
> all we have to do AFAICS is generate a URL pointing to a consistent
> version of the templates.
>

I wasn't aware of this feature, I'll take a look but that sounds useful.


>
> >We had a few suggestions in the meeting:
> >
> >Â - Add a locking mechanism. I would be concerned about deadlocks or
> >having to
> >Â Â  lock for the full duration of a deploy.
>
> I think we need to create a new version of a plan every time it's modified,
> then on deployment the concern around locking is much reduced, or even
> eliminated?
>

Yup, if we essentially make everything immutable that would solve a number
of issues.



> >Â - Store the files in a tarball (so we only deal with one file). I
> think
> >we
> >Â Â  could still hit issues with multiple operations unless we
> guarantee
> >that
> >Â Â  only one instance of the API is ever running.
> >
> >I think these could potentially be made to work, but at this point
> are we
> >using the best tool for the job?
> >
> >For alternatives, I see a can think of a couple of options:
> >
> >- Use a database, like we did for Tuskar and most OpenStack API's do.
>
> Storing template files in a database with Tuskar was a mistake - we should
> *not* do that again IMO - it was a very opaque interface and caused a lot
> of confusion in use.
>

The interface is via the API, so I don't see how the storage mechanism would
change that. We could change the current WIP code to use a database or
git or anything else without changing the interface. Perhaps we need to
focus
more on what interface we need and the specific problems with the one Tuskar
provided? I thought the primary issue with Tuskar was with the template
mangling and not the actual process of accessing the templates etc.


Storing code (in this case yaml files) in some sort of versioned repository
> is *such* a solved problem - it'll be total wheel-reinventing if we
> implement template revision control inside a bespoke DB IMHO.
>

It's interesting that you mention revision control - this IIRC hasn't been
a topic
mentioned in any of the specs. It might be that we need to step back and
look
at this topic more in general.


I think swift is probably a workable solution (using versioning and
> tempurl's), but we should really consider making the 

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Tomas Sedovic]

On 12/23/2015 01:01 PM, Steven Hardy wrote:

On Tue, Dec 22, 2015 at 03:36:02PM +, Dougal Matthews wrote:

Hi all,

This topic came up in the 2015-12-15 meeting[1], and again briefly today.
After working with the code that came out of the deployment library
spec[2] I
had some concerns with how we are storing the templates.

Simply put, when we are dealing with 100+ files from
tripleo-heat-templates
how can we ensure consistency in Swift without any atomicity or
transactions.
I think this is best explained with a couple of examples.

 - When we create a new deployment plan (upload all the templates to
swift)
   how do we handle the case where there is an error? For example, if we
are
   uploading 10 files - what do we do if the 5th one fails for some
reason?
   There is a patch to do a manual rollback[3], but I have concerns
about
   doing this in Python. If Swift is completely inaccessible for a short
   period the rollback wont work either.


How does using a different data store help fix this error path?

Regardless of the Swift/DB/Git choice, you have to detect something failed,
and mark the plan as in a failed state.


 - When deploying to Heat, we need to download all the YAML files from
Swift.
   This can take a couple of seconds. What happens if somebody starts to
   upload a new version of the plan in the middle? We could end up
trying to
   deploy half old and half new files. We wouldn't have a consistent
view of
   the database.


If this happens, the API design is wrong - we should have a plan reference
a unique identifier, including a version (e.g through swift versioned
objects, git tags/branches or whatever), then on deployment heat should
download exactly one version of those artefacts (e.g via a swift tempurl or
a git URL, or whatever).

FYI heatclient already supports downloading template objects directly from
swift, and heat/heatclient already support downloading from http URLs, so
all we have to do AFAICS is generate a URL pointing to a consistent
version of the templates.


We had a few suggestions in the meeting:

 - Add a locking mechanism. I would be concerned about deadlocks or
having to
   lock for the full duration of a deploy.


I think we need to create a new version of a plan every time it's modified,
then on deployment the concern around locking is much reduced, or even
eliminated?


 - Store the files in a tarball (so we only deal with one file). I think
we
   could still hit issues with multiple operations unless we guarantee
that
   only one instance of the API is ever running.

I think these could potentially be made to work, but at this point are we
using the best tool for the job?

For alternatives, I see a can think of a couple of options:

- Use a database, like we did for Tuskar and most OpenStack API's do.


Storing template files in a database with Tuskar was a mistake - we should
*not* do that again IMO - it was a very opaque interface and caused a lot
of confusion in use.

Storing code (in this case yaml files) in some sort of versioned repository
is *such* a solved problem - it'll be total wheel-reinventing if we
implement template revision control inside a bespoke DB IMHO.

I think swift is probably a workable solution (using versioning and
tempurl's), but we should really consider making the template store
pluggable, as having the API backed by an (operator visible) git repo is
likely to be a nicer and more familiar solution.

The question around validation data I'm less clear on - we already store
discovery data in swift, which seems to work OK - how is the validation
data different, in that it warrants a bespoke DB data store?


Each validation result is quite small (basically passed/failed, 
date of the run, and which stage and validation it corresponds to).


We'll want to be able to query them per stage, validation and plan, sort 
them by the time and possibly use select validations within a certain 
time span.


We can just store them in Swift, but then we'd have to write the code 
that maintains the indexes and filters the objects based on a given 
query. The validations can run in parallel, so we need to make sure the 
indexes are updated atomically (or not use indexes at all and always 
load all the results).


All that is certainly feasible, but it's also something that a database 
does out of the box. We're talking about a single table and 3-4 SELECT 
statements (or the equivalent in Mongo, etc.).




Steve

__
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] [infra][release][all] Automatic .ics generation for OpenStack's and project's deadlines

[Doug Hellmann]

Excerpts from Louis Taylor's message of 2015-12-13 08:09:24 +:
> On Thu, Dec 10, 2015 at 06:20:44PM +, Flavio Percoco wrote:
> > Greetings,
> > 
> > I'd like to explore the possibility of having .ics generated - pretty
> > much the same way we generate it for irc-meetings - for the OpenStack
> > release schedule and project's deadlines. I believe just 1 calendar
> > would be enough but I'd be ok w/  a per-project .ics too.
> > 
> > With the new home for the release schedule, and it being a good place
> > for projects to add their own deadlines as well, I believe it would be
> > good for people that use calendars to have these .ics being generated
> > and linked there as well.
> > 
> > Has this been attempted? Any objections? Is there something I'm not
> > considering?
> 
> I had a bit of time and started hacking up a simple version of this:
> 
> https://github.com/kragniz/release-schedule-generator
> 
> The output of this may or may not be standards-compliant, but google calendar
> appears to accept it. You can see example output here:
> 
> https://kragniz.eu/pub/schedule.ics
> 
> There's currently no support for project-specific events or RST output, but
> these can be added later if people think this current implementation isn't too
> bad.
> 
> Feel free to send feedback or (even better) pull requests in my direction if
> this seems okay.
> 
> Cheers,
> Louis

What you have is a really good start. Thanks for working on this!
How do you feel about importing the repository into gerrit?

A couple of things I'd like to see added:

1. Separate sections for cross-project and project-specific events.

   This would let us completely generate the RST content, as it
   appears on http://docs.openstack.org/releases/schedules/mitaka.html,
   as well as generate project-specific ICS files (some folks may want
   to only subscribe to cross-project events and their own project's
   schedule).

2. Durations for individual events.

   This would let us have single-day events, such as the final
   release date, as well as include things like mid-cycle meetings,
   sprints, etc. that may not all last 4 days.

3. The "generator" python package directory will probably need to
   be renamed to something more descriptive to let this be installed
   with other projects, which we'll need in order to integrate it with
   Sphinx.

4. That Sphinx integration will be easier if the function to construct
   the data structure representing the schedule data is separated from
   the function to format the data in different ways. That's just
   refactoring some of what's already there, so it's not a big deal.

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] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Bulat Gaifullin]

+1

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 23 Dec 2015, at 17:29, Aleksey Kasatkin  wrote:
> 
> +1
> 
> Aleksey Kasatkin 
> 
> 
> On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko  > wrote:
> +1
> 
> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich  > wrote:
> Absolutely agree 
> 
> +1 
> 
> 
> 
> 
> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy 
> > wrote:
> Hi guys,
> I'd like to nominate Artem Panchenko [0] for fuel-qa core.
> 
> Artem has great technical expertise in fuel-qa and he developed a lot of 
> vital parts of framework. His first place in a number of commits is a good 
> proof of that.
> His reviews are always thorough and consistent.
> Please, vote for Artem!
> 
> [0] 
> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
>  
> 
> 
> -- 
> Thanks, 
> Andrey Sledzinskiy  
> QA Engineer, 
> Mirantis, Kharkiv
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack 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] [Fuel] Nominate Artem Roma for fuel-ostf core

[Andrey Sledzinskiy]

+1

On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich <
tleontov...@mirantis.com> wrote:

> Hi guys,
> I'd like to nominate Artem Roma [0] for fuel-ostf core.
>
> Artem  cares about fuel-ostf more then 2 years, always provide a great
> reviews(always thorough and consistent and comes in time), extend unit
> tests coverages and provide a lot of bug fixes and improvements there.
>
> Please, vote for Artem!
>
>
> http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf
>
> __
> 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
>
>


-- 
Thanks,
Andrey Sledzinskiy
QA Engineer,
Mirantis, Kharkiv
__
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] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Aleksandr Didenko]

+1

On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich <
tleontov...@mirantis.com> wrote:

> Absolutely agree
>
> +1
>
>
>
>
> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy <
> asledzins...@mirantis.com> wrote:
>
>> Hi guys,
>> I'd like to nominate Artem Panchenko [0] for fuel-qa core.
>>
>> Artem has great technical expertise in fuel-qa and he developed a lot of
>> vital parts of framework. His first place in a number of commits is a good
>> proof of that.
>> His reviews are always thorough and consistent.
>> Please, vote for Artem!
>>
>> [0]
>> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
>>
>> --
>> Thanks,
>> Andrey Sledzinskiy
>> QA Engineer,
>> Mirantis, Kharkiv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 23 December 2015 at 12:01, Steven Hardy  wrote:

> On Tue, Dec 22, 2015 at 03:36:02PM +, Dougal Matthews wrote:
> >Hi all,
> >
> >This topic came up in the 2015-12-15 meeting[1], and again briefly
> today.
> >After working with the code that came out of the deployment library
> >spec[2] I
> >had some concerns with how we are storing the templates.
> >
> >Simply put, when we are dealing with 100+ files from
> >tripleo-heat-templates
> >how can we ensure consistency in Swift without any atomicity or
> >transactions.
> >I think this is best explained with a couple of examples.
> >
> >Â - When we create a new deployment plan (upload all the templates to
> >swift)
> >Â Â  how do we handle the case where there is an error? For example,
> if we
> >are
> >Â Â  uploading 10 files - what do we do if the 5th one fails for some
> >reason?
> >Â Â  There is a patch to do a manual rollback[3], but I have concerns
> >about
> >Â Â  doing this in Python. If Swift is completely inaccessible for a
> short
> >Â Â  period the rollback wont work either.
>
> How does using a different data store help fix this error path?
>
> Regardless of the Swift/DB/Git choice, you have to detect something failed,
> and mark the plan as in a failed state.
>
> >Â - When deploying to Heat, we need to download all the YAML files
> from
> >Swift.
> >Â Â  This can take a couple of seconds. What happens if somebody
> starts to
> >Â Â  upload a new version of the plan in the middle? We could end up
> >trying to
> >Â Â  deploy half old and half new files. We wouldn't have a consistent
> >view of
> >Â Â  the database.
>
> If this happens, the API design is wrong - we should have a plan reference
> a unique identifier, including a version (e.g through swift versioned
> objects, git tags/branches or whatever), then on deployment heat should
> download exactly one version of those artefacts (e.g via a swift tempurl or
> a git URL, or whatever).
>

Swift gives us no way to get the current version. In a versioned container,
the
current version is referenced by the file path only, the previous versions
are
the file path with a timestamp. So there is no way to reference an object
and
not see updates unless we start tracking timestamps etc. in code.

I hope I am understanding it correctly, this was one of the primary reasons
that we discounted Swift as an option for Tuskar when I was looking into
versioning around a year ago. I've had a look again and it seems the
situation
hasn't changed (but I will double check now).


>
> FYI heatclient already supports downloading template objects directly from
> swift, and heat/heatclient already support downloading from http URLs, so
> all we have to do AFAICS is generate a URL pointing to a consistent
> version of the templates.
>
> >We had a few suggestions in the meeting:
> >
> >Â - Add a locking mechanism. I would be concerned about deadlocks or
> >having to
> >Â Â  lock for the full duration of a deploy.
>
> I think we need to create a new version of a plan every time it's modified,
> then on deployment the concern around locking is much reduced, or even
> eliminated?
>
> >Â - Store the files in a tarball (so we only deal with one file). I
> think
> >we
> >Â Â  could still hit issues with multiple operations unless we
> guarantee
> >that
> >Â Â  only one instance of the API is ever running.
> >
> >I think these could potentially be made to work, but at this point
> are we
> >using the best tool for the job?
> >
> >For alternatives, I see a can think of a couple of options:
> >
> >- Use a database, like we did for Tuskar and most OpenStack API's do.
>
> Storing template files in a database with Tuskar was a mistake - we should
> *not* do that again IMO - it was a very opaque interface and caused a lot
> of confusion in use.
>
> Storing code (in this case yaml files) in some sort of versioned repository
> is *such* a solved problem - it'll be total wheel-reinventing if we
> implement template revision control inside a bespoke DB IMHO.
>
> I think swift is probably a workable solution (using versioning and
> tempurl's), but we should really consider making the template store
> pluggable, as having the API backed by an (operator visible) git repo is
> likely to be a nicer and more familiar solution.
>
> The question around validation data I'm less clear on - we already store
> discovery data in swift, which seems to work OK - how is the validation
> data different, in that it warrants a bespoke DB data store?
>
> Steve
>
> __
> 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] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Aleksey Kasatkin]

+1

Aleksey Kasatkin


On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko 
wrote:

> +1
>
> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich <
> tleontov...@mirantis.com> wrote:
>
>> Absolutely agree
>>
>> +1
>>
>>
>>
>>
>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy <
>> asledzins...@mirantis.com> wrote:
>>
>>> Hi guys,
>>> I'd like to nominate Artem Panchenko [0] for fuel-qa core.
>>>
>>> Artem has great technical expertise in fuel-qa and he developed a lot of
>>> vital parts of framework. His first place in a number of commits is a good
>>> proof of that.
>>> His reviews are always thorough and consistent.
>>> Please, vote for Artem!
>>>
>>> [0]
>>> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
>>>
>>> --
>>> Thanks,
>>> Andrey Sledzinskiy
>>> QA Engineer,
>>> Mirantis, Kharkiv
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Tatyana Leontovich]

Absolutely agree

+1




On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy <
asledzins...@mirantis.com> wrote:

> Hi guys,
> I'd like to nominate Artem Panchenko [0] for fuel-qa core.
>
> Artem has great technical expertise in fuel-qa and he developed a lot of
> vital parts of framework. His first place in a number of commits is a good
> proof of that.
> His reviews are always thorough and consistent.
> Please, vote for Artem!
>
> [0]
> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
>
> --
> Thanks,
> Andrey Sledzinskiy
> QA Engineer,
> Mirantis, Kharkiv
>
> __
> 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] [glance][artifacts][app-catalog] Proposal to move artifacts meeting time

[Alexander Tivelkov]

Thanks for voting.

The most popular option is 17:00 UTC Mondays. Unfortunately the
#openstack-meeting-4 channel turned out to be occupied at this timeslot, so
I propose to change the channel to #openstack-meeting-alt

I've submitted a patch to irc-meeting infra repo:
https://review.openstack.org/#/c/260998
Please vote for that patch if the channel change is ok to you.

Thanks!

On Mon, Dec 21, 2015 at 6:34 AM Nikhil Komawar 
wrote:

> Thanks Alex. This is a good idea. Please propose a review for the change
> of schedule so that we can be assured the tests pass and decision would be
> accepted.
>
>
> On 12/18/15 9:20 AM, Alexander Tivelkov wrote:
>
> Hi folks,
>
> The current timeslot of our weekly IRC meeting for artifact subteam (14:00
> UTC Mondays) seems a bit inconvenient: it's a bit early for people in the
> Pacific timezone. Since we want to maximise the presence of all the
> interested parties at our sync-ups, I'd propose to move our meeting to some
> later timeslot. I'd prefer it to remain in #openstack-meeting-4 (since all
> the rest Glancy meetings are there) and be several days ahead of the main
> Glance meeting (which is on Thursdays).
>
> I've checked the current openstack meetings schedule and found some slots
> which may be more convenient then the current one. I've put them in doodle
> at http://doodle.com/poll/7krdfp96kttnvmg7 - please vote there for the
> slots which are ok for you. Then I'll make a patch to irc-meetings infra
> repo.
>
> Thanks!
> --
> Regards,
> Alexander Tivelkov
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
>
> Thanks,
> Nikhil
>
> __
> 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
>
-- 
Regards,
Alexander Tivelkov
__
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] [Fuel] Nominate Artem Roma for fuel-ostf core

[Aleksey Kasatkin]

+1

Aleksey Kasatkin


On Wed, Dec 23, 2015 at 5:28 PM, Aleksandr Didenko 
wrote:

> +1
>
> On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy <
> asledzins...@mirantis.com> wrote:
>
>> +1
>>
>> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich <
>> tleontov...@mirantis.com> wrote:
>>
>>> Hi guys,
>>> I'd like to nominate Artem Roma [0] for fuel-ostf core.
>>>
>>> Artem  cares about fuel-ostf more then 2 years, always provide a great
>>> reviews(always thorough and consistent and comes in time), extend unit
>>> tests coverages and provide a lot of bug fixes and improvements there.
>>>
>>> Please, vote for Artem!
>>>
>>>
>>> http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Andrey Sledzinskiy
>> QA Engineer,
>> Mirantis, Kharkiv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Mesos Conductor

[bharath thiruveedula]

Hi,
As per the discussion in [1], I have pushed patchset [1]. Can you please review 
 the patch. I want to take comments on this patch before I push test cases and 
container-list operation because there was a discussion on this topic whether 
to have this or not. (from my previous experience :) ). 
RegardsBharath T
[1]http://lists.openstack.org/pipermail/openstack-dev/2015-December/081818.html[2]https://review.openstack.org/#/c/258860/
__
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] [Horizon][Neutron] dashboard repository for neutron subprojects

[Fawad Khaliq]

On Wed, Dec 23, 2015 at 9:16 PM, Akihiro Motoki  wrote:

> Are there no comment after I added more detail?
> No inputs from both horizon and neutron side.
>
> Although Horizon team is tackling to address some problems around
> horizon plugin mechanism
> such as translations, I think option (c) requires neutron subprojects
> to do some extra efforts
> around infra scripts. They are specific to neutron subproject
> directory structure and neutron
> subprojects should be responsible to deal with them as option (c) is a
> choice of neutron side.
> please check the details of my previous post.
>
> I am not sure it is okay to neutron suboprojects?
>
I think option (c) would work fine. My vote would be to go with it. Would
be best if someone could capture a devref around this similar to what
HenryG did around DB and alembic for subprojects.

>
> Akihiro
>
>
> 2015-12-02 17:23 GMT+09:00 Akihiro Motoki :
> > Thanks all.
> > All comments so far are from neutron side. I would like to wait inputs
> > from horizon side, especially David.
> >
> > Option (c) is what we do in neutron sub-projects under neutron stadium
> model and
> > I agree it makes sense and sounds natural to neutron folks.
> >
> > My initial mail just did not cover technical points or horizon
> > developer perspective
> > if we go to option (c). Let me share them.
> >
> > [Horizon developer perspective]
> >
> > I think we need some collaboration points between neutron subprojects
> > and horizon team (+ UX team).
> > to share knowledge or conventions in the dashboard development.
> > Not so many neutron developers are aware of horizon side changes, so I
> > think Horizon side
> > needs to care of these repositories to some extent for better UX
> > consistency or framework changes.
> >
> > We are going to the self-management models in individual repos, so I
> believe
> > each team watches horizon side changes to some extent, and keep their
> > dashboard up-to-date.
> >
> > From Horizon point of view, it seems good to me if the following are
> done:
> >
> > - Use a consistent directory name for a dashboard support in each
> > repository (e.g., "dashboard")
> >   Gerrit support filename based query, so it allows horizon developers
> > can reach dashboard related reviews.
> > - Keep up-to-date Horizon plugin registry
> > http://docs.openstack.org/developer/horizon/plugins.html
> > - Use horizon plugin model rather than adhoc approach
> > - Documentation on config options (at now, horizon does not support
> > oslo.config generator)
> >
> > [Technical topics]
> >
> > - We need to have two testing setup for both neutron and horizon.
> >   I think most dashboard tests depend on Horizon (or at least Django)
> >
> > - Does (test-)requirements.txt contain neutron and horizon dependencies?
> >   For horizon itself, perhaps no. Our test tool chains should install
> horizon
> >   as we do for neutron dependency.
> >   For other requirements, I am not sure at this moment.
> >
> > - Separate translation support for dashboard and server code.
> >   Django and oslo.i18n (python gettext) use different approach to find
> > translation catalog,
> >   so we need to prepare a separate tool chain for both translation
> catalog.
> >   It requires the infra script change.
> >
> >   # Normal Horizon plugin translation support is an ongoing effort,
> >   # but option (c) needs extra effort.
> >
> > [Packaging perspective]
> >
> > I am not sure how it affects.
> > There is one concern as a package consumer.
> >
> >> Getting additional packages through distro channels can be surprisingly
> difficult for new packages. :/
> >
> > How neutron team can answer to this?
> > I think it is not specific to neutron subproject dashboard discussion.
> > Neutron stadium mode already has this problem.
> > Input from packaging side would be appreciated.
> >
> > Thanks,
> > Akihiro
> >
> > 2015-11-25 14:46 GMT+09:00 Akihiro Motoki :
> >> Hi,
> >>
> >> Neutron has now various subprojects and some of them would like to
> >> implement Horizon supports. Most of them are additional features.
> >> I would like to start the discussion where we should have horizon
> support.
> >>
> >> [Background]
> >> Horizon team introduced a plugin mechanism and we can add horizon panels
> >> from external repositories. Horizon team is recommending external repos
> for
> >> additional services for faster iteration and features.
> >> We have various horizon related repositories now [1].
> >>
> >> In Neutron related world, we have neutron-lbaas-dashboard and
> >> horizon-cisco-ui repos.
> >>
> >> [Possible options]
> >> There are several possible options for neutron sub-projects.
> >> My current vote is (b), and the next is (a). It looks a good balance to
> me.
> >> I would like to gather broader opinions,
> >>
> >> (a) horizon in-tree repo
> >> - [+] It was a legacy approach and there is no initial effort to setup
> a repo.
> >> - [+] Easy to share code 

Re: [openstack-dev] Nova scheduler startup when database is not available

[Jay Pipes]

On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote:

I've been looking into the startup constraints involved when launching
Nova services with systemd using Type=notify (which causes systemd to
wait for an explicit notification from the service before considering
it to be "started".  Some services (e.g., nova-conductor) will happily
"start" even if the backing database is currently unavailable (and
will enter a retry loop waiting for the database).

Other services -- specifically, nova-scheduler -- will block waiting
for the database *before* providing systemd with the necessary
notification.

nova-scheduler blocks because it wants to initialize a list of
available aggregates (in scheduler.host_manager.HostManager.__init__),
which it gets by calling objects.AggregateList.get_all.

Does it make sense to block service startup at this stage?  The
database disappearing during runtime isn't a hard error -- we will
retry and reconnect when it comes back -- so should the same situation
at startup be a hard error?  As an operator, I am more interested in
"did my configuration files parse correctly?" at startup, and would
generally prefer the service to start (and permit any dependent
services to start) even when the database isn't up (because that's
probably a situation of which I am already aware).


If your configuration file parsed correctly but has the wrong database 
connection URI, what good is the service in an active state? It won't be 
able to do anything at all.


This is why I think it's better to have hard checks like for connections 
on startup and not have services active if they won't be able to do 
anything useful.



It would be relatively easy to have the scheduler lazy-load the list
of aggregates on first references, rather than at __init__.


Sure, but if the root cause of the issue is a problem due to 
misconfigured connection string, then that lazy-load will just bomb out 
and the scheduler will be useless anyway. I'd rather have a 
fail-early/fast occur here than a fail-late.


Best,
-jay

> I'm not

familiar enough with the nova code to know if there would be any
undesirable implications of this behavior.  We're already punting
initializing the list of instances to an asynchronous task in order to
avoid blocking service startup.

Does it make sense to permit nova-scheduler to complete service
startup in the absence of the database (and then retry the connection
in the background)?



__
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] [Cinder] No IRC meeting December 30

[Sean McGinnis]

Hey all,

Do to the holidays and travel there will be no meeting next Wednesday,
December 30th. We will resume the following week.

Have a good break!

Sean (smcginnis)

__
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] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Igor Marnat]

Folks,
I'm not a fuel-qa core, but if I was, I'd vote with +1:)

I'm really impressed with quality of analysis which Artem provides in bug
reports and his overall help with bugs resolving. Keep going!

Regards,
Igor Marnat

On Wed, Dec 23, 2015 at 8:05 PM, Igor Kalnitsky 
wrote:

> Artem is doing a great job! Definitely +1.
>
> On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin
>  wrote:
> > +1
> >
> > Regards,
> > Bulat Gaifullin
> > Mirantis Inc.
> >
> >
> >
> > On 23 Dec 2015, at 17:29, Aleksey Kasatkin 
> wrote:
> >
> > +1
> >
> > Aleksey Kasatkin
> >
> >
> > On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko <
> adide...@mirantis.com>
> > wrote:
> >>
> >> +1
> >>
> >> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich
> >>  wrote:
> >>>
> >>> Absolutely agree
> >>>
> >>> +1
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy
> >>>  wrote:
> 
>  Hi guys,
>  I'd like to nominate Artem Panchenko [0] for fuel-qa core.
> 
>  Artem has great technical expertise in fuel-qa and he developed a lot
> of
>  vital parts of framework. His first place in a number of commits is a
> good
>  proof of that.
>  His reviews are always thorough and consistent.
>  Please, vote for Artem!
> 
>  [0]
> 
> http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa
> 
>  --
>  Thanks,
>  Andrey Sledzinskiy
>  QA Engineer,
>  Mirantis, Kharkiv
> 
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >>>
> >>>
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] [fuel] RabbitMQ in dedicated network

[Andrew Maksimov]

Hi Kirill,

I don't think we can give up on using fqdn node names for RabbitMQ because
we need to support TLS in the future.

Thanks,
Andrey Maximov
Fuel Project Manager

On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov 
wrote:

> Hello,
>
> I would like to start discussion regarding the issue we have discovered
> recently [1].
>
> In a nutshell, if RabbitMQ is configured to run in separate mgmt/messaging
> network it fails on building cluster.
> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is
> built using FQDN. Apparently, FQDN resolves to admin network which is
> different in this particular case.
> As a result, RabbitMQ on secondary controller node fails to join to
> primary controller node.
>
> I can suggest two ways to tackle the issue: one is pretty simple, while
> other is not.
>
> The first way is to accept by design using admin network for RabbitMQ
> internal communication between controller nodes.
>
> The second way is to dig into pacemaker and RabbitMQ reconfiguration.
> Since it requires to refuse from using common fqdn/node names, this
> approach can be argued.
>
>
> --
> [1] https://bugs.launchpad.net/fuel/+bug/1528707
>
> Best regards,
> Kyrylo
>
> __
> 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] [fuel] RabbitMQ in dedicated network

[Matthew Mosesohn]

I agree. As far as I remember, rabbit needs fqdns to work and map
correctly. I think it means we should disable the ability to move the
internal messaging network role in order to fix this bug until we can add
extra dns entries per network role (or at least addr)
On Dec 23, 2015 8:42 PM, "Andrew Maksimov"  wrote:

> Hi Kirill,
>
> I don't think we can give up on using fqdn node names for RabbitMQ because
> we need to support TLS in the future.
>
> Thanks,
> Andrey Maximov
> Fuel Project Manager
>
> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov 
> wrote:
>
>> Hello,
>>
>> I would like to start discussion regarding the issue we have discovered
>> recently [1].
>>
>> In a nutshell, if RabbitMQ is configured to run in separate
>> mgmt/messaging network it fails on building cluster.
>> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is
>> built using FQDN. Apparently, FQDN resolves to admin network which is
>> different in this particular case.
>> As a result, RabbitMQ on secondary controller node fails to join to
>> primary controller node.
>>
>> I can suggest two ways to tackle the issue: one is pretty simple, while
>> other is not.
>>
>> The first way is to accept by design using admin network for RabbitMQ
>> internal communication between controller nodes.
>>
>> The second way is to dig into pacemaker and RabbitMQ reconfiguration.
>> Since it requires to refuse from using common fqdn/node names, this
>> approach can be argued.
>>
>>
>> --
>> [1] https://bugs.launchpad.net/fuel/+bug/1528707
>>
>> Best regards,
>> Kyrylo
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

[Alexey Lebedeff]

When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME
environment variable), you could actually use IP-address as a node name.

Matthew Mosesohn writes:

> I agree. As far as I remember, rabbit needs fqdns to work and map
> correctly. I think it means we should disable the ability to move the
> internal messaging network role in order to fix this bug until we can add
> extra dns entries per network role (or at least addr)
> On Dec 23, 2015 8:42 PM, "Andrew Maksimov"  wrote:
>
>> Hi Kirill,
>>
>> I don't think we can give up on using fqdn node names for RabbitMQ because
>> we need to support TLS in the future.
>>
>> Thanks,
>> Andrey Maximov
>> Fuel Project Manager
>>
>> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov 
>> wrote:
>>
>>> Hello,
>>>
>>> I would like to start discussion regarding the issue we have discovered
>>> recently [1].
>>>
>>> In a nutshell, if RabbitMQ is configured to run in separate
>>> mgmt/messaging network it fails on building cluster.
>>> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is
>>> built using FQDN. Apparently, FQDN resolves to admin network which is
>>> different in this particular case.
>>> As a result, RabbitMQ on secondary controller node fails to join to
>>> primary controller node.
>>>
>>> I can suggest two ways to tackle the issue: one is pretty simple, while
>>> other is not.
>>>
>>> The first way is to accept by design using admin network for RabbitMQ
>>> internal communication between controller nodes.
>>>
>>> The second way is to dig into pacemaker and RabbitMQ reconfiguration.
>>> Since it requires to refuse from using common fqdn/node names, this
>>> approach can be argued.
>>>
>>>
>>> --
>>> [1] https://bugs.launchpad.net/fuel/+bug/1528707
>>>
>>> Best regards,
>>> Kyrylo

__
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] Is Swift a good choice of database for the TripleO API?

[Steven Hardy]

On Wed, Dec 23, 2015 at 11:05:05AM -0600, Ben Nemec wrote:
> On 12/23/2015 10:26 AM, Steven Hardy wrote:
> > On Wed, Dec 23, 2015 at 09:28:59AM -0600, Ben Nemec wrote:
> >> On 12/23/2015 03:19 AM, Dougal Matthews wrote:
> >>>
> >>>
> >>> On 22 December 2015 at 17:59, Ben Nemec  >>> > wrote:
> >>>
> >>> Can we just do git like I've been suggesting all along? ;-)
> >>>
> >>> More serious discussion inline. :-)
> >>>
> >>> On 12/22/2015 09:36 AM, Dougal Matthews wrote:
> >>> > Hi all,
> >>> >
> >>> > This topic came up in the 2015-12-15 meeting[1], and again briefly
> >>> today.
> >>> > After working with the code that came out of the deployment library
> >>> > spec[2] I
> >>> > had some concerns with how we are storing the templates.
> >>> >
> >>> > Simply put, when we are dealing with 100+ files from
> >>> tripleo-heat-templates
> >>> > how can we ensure consistency in Swift without any atomicity or
> >>> > transactions.
> >>> > I think this is best explained with a couple of examples.
> >>> >
> >>> >  - When we create a new deployment plan (upload all the templates
> >>> to swift)
> >>> >how do we handle the case where there is an error? For example,
> >>> if we are
> >>> >uploading 10 files - what do we do if the 5th one fails for
> >>> some reason?
> >>> >There is a patch to do a manual rollback[3], but I have
> >>> concerns about
> >>> >doing this in Python. If Swift is completely inaccessible for a
> >>> short
> >>> >period the rollback wont work either.
> >>> >
> >>> >  - When deploying to Heat, we need to download all the YAML files 
> >>> from
> >>> > Swift.
> >>> >This can take a couple of seconds. What happens if somebody
> >>> starts to
> >>> >upload a new version of the plan in the middle? We could end up
> >>> trying to
> >>> >deploy half old and half new files. We wouldn't have a
> >>> consistent view of
> >>> >the database.
> >>> >
> >>> > We had a few suggestions in the meeting:
> >>> >
> >>> >  - Add a locking mechanism. I would be concerned about deadlocks or
> >>> > having to
> >>> >lock for the full duration of a deploy.
> >>>
> >>> There should be no need to lock the plan for the entire deploy.  It's
> >>> not like we're re-reading the templates at the end of the deploy 
> >>> today.
> >>>  It's a one-shot read and then the plan could be unlocked, at least as
> >>> far as I know.
> >>>
> >>>
> >>> Good point. That would be holding the lock for longer than we need.
> >>>  
> >>>
> >>> The only option where we wouldn't need locking at all is the
> >>> read-copy-update model Clint mentions, which might be a valid option 
> >>> as
> >>> well.  Whatever we do, there are going to be concurrency issues 
> >>> though.
> >>>  For example, what happens if two users try to make updates to the 
> >>> plan
> >>> at the same time?  If you don't either merge the changes or disallow 
> >>> one
> >>> of them completely then one user's changes might be lost.
> >>>
> >>> TBH, this is further convincing me that we should just make this git
> >>> backed and let git handle the merging and conflict resolution (never
> >>> mind the fact that it gets us a well-understood version control system
> >>> for "free").  For updates that don't conflict with other changes, git
> >>> can merge them automatically, but for merge conflicts you just return 
> >>> a
> >>> rebase error to the user and make them resolve it.  I have a feeling
> >>> this is the behavior we'll converge on eventually anyway, and rather
> >>> than reimplement git, let's just use the real thing.
> >>>
> >>>
> >>> I'd be curious to hear more how you would go about doing this with git. 
> >>> I've
> >>> never automated git to this level, so I am concerned about what issues we
> >>> might hit.
> >>
> >> TBH I haven't thought it through to that extent yet.  I'm mostly
> >> suggesting it because it seems like a fit for the template storage
> >> requirements - we know we want version control, we want to be able to
> >> merge changes from multiple sources, and we want some way to handle
> >> merge conflicts.  Git does all of this already.
> >>
> >> That said, I'm not sure about everything here.  For example, how would
> >> you expose merge conflicts to the user?  I don't know that I would want
> >> to force a user to learn git in order to use TripleO (although that
> >> would be the devops-y thing to do), but maybe just passing them back the
> >> files with the merge conflict markers and having them resolve those
> >> locally and retry the update would work.  I'm not sure how that would
> >> map to the current version of the API though.  Do we provide any way to
> >> pass templates back to the user?  I feel like that 

Re: [openstack-dev] [Fuel][Multirack] Are we going to support Ceph Multirack deployments?

[Roman Sokolkov]

+ Konstantin and Alex

Can someone give a quick highlight on that question?

On Tue, Dec 22, 2015 at 8:17 PM, Roman Sokolkov 
wrote:

> Folks,
>
> multirack is going to be a part of MOS 8.0.
>
> But i can not find any info about Ceph?
>
> Technically Ceph supports Multiple L3 networks [1].
>
> [1] -
> http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/#network-config-settings
>
> --
> Roman Sokolkov,
> Deployment Engineer,
> Mirantis, Inc.
> Skype rsokolkov,
> rsokol...@mirantis.com
>



-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
__
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] [Fuel] Nominate Artem Roma for fuel-ostf core

[Igor Kalnitsky]

I believe fuel-ostf project needs a python dev to take care of
adapter. So +1 from my side.

P.S: I'm not a fuel-ostf core, but I think Dmitry S. doesn't show any
attention to this project. In order to maintain a high quality of
code, I'd consider to remove him from this group.

On Wed, Dec 23, 2015 at 5:28 PM, Aleksandr Didenko
 wrote:
> +1
>
> On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy
>  wrote:
>>
>> +1
>>
>> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich
>>  wrote:
>>>
>>> Hi guys,
>>> I'd like to nominate Artem Roma [0] for fuel-ostf core.
>>>
>>> Artem  cares about fuel-ostf more then 2 years, always provide a great
>>> reviews(always thorough and consistent and comes in time), extend unit tests
>>> coverages and provide a lot of bug fixes and improvements there.
>>>
>>> Please, vote for Artem!
>>>
>>>
>>> http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>>
>> --
>> Thanks,
>> Andrey Sledzinskiy
>> QA Engineer,
>> Mirantis, Kharkiv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [fuel] RabbitMQ in dedicated network

[Kyrylo Galanov]

Hello,

I would like to start discussion regarding the issue we have discovered
recently [1].

In a nutshell, if RabbitMQ is configured to run in separate mgmt/messaging
network it fails on building cluster.
While RabbitMQ is managed by Pacemaker and OCF script, the cluster is built
using FQDN. Apparently, FQDN resolves to admin network which is different
in this particular case.
As a result, RabbitMQ on secondary controller node fails to join to primary
controller node.

I can suggest two ways to tackle the issue: one is pretty simple, while
other is not.

The first way is to accept by design using admin network for RabbitMQ
internal communication between controller nodes.

The second way is to dig into pacemaker and RabbitMQ reconfiguration. Since
it requires to refuse from using common fqdn/node names, this approach can
be argued.


--
[1] https://bugs.launchpad.net/fuel/+bug/1528707

Best regards,
Kyrylo
__
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] [devstack][QA] Changing logging format to match documented defaults

[Ronald Bradford]

Ian,


On Tue, Dec 22, 2015 at 3:22 PM, Ian Wienand  wrote:
>
> On 12/23/2015 05:55 AM, Ronald Bradford wrote:
> > I have observed that devstack uses custom logging formatting that
> > differs from the documented defaults. An example is for nova.  which
> > is defined in [1]
>
> The original point mentioned there of using "*_name" for extra
> verbosity still seems relevant [1]
>
> > logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
> > %(name)s [%(request_id)s *%(user_identity)s*] %(instance)s%(message)s
>
> user_identity is still just "{user} {tenant} ..." (which is id's, I
> believe?) [2].


For reference, here are messages using before and after suggestions with
and without context. Presently, the default value defines 5 distinct
components including user and tenant/project.

Before:

2015-12-18 18:22:52.788 DEBUG oslo_concurrency.lockutils
[*req-bcd393ce-523e-454e-b05a-7b80f82aaaf0
None None*] Acquired semaphore "singleton_lock" lock
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:197

2015-12-23 17:21:12.570 DEBUG nova.quota
[*req-a65d797f-1e7e-48b4-a0b7-92f48e5f6bcd
admin demo*] Quota limits for project 9c011aa5646640abae282b9093515333:
{'project_id': u'9c011aa5646640abae282b9093515333'} reserve
/opt/stack/nova/nova/quota.py:559

After:

2015-12-18 18:28:10.890 DEBUG oslo_concurrency.lockutils
[*req-2d7df976-5004-4da2-83cc-2ed96ee42049
- - - - -*] Acquired semaphore "singleton_lock" lock
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:197

2015-12-23 17:24:44.228 11197 DEBUG nova.quota
[*req-bfc10adf-5a05-4fd1-a671-32547f48f391
bc455368223742729898fb85c995694d 9c011aa5646640abae282b9093515333 - - -*]
Quota limits for project 9c011aa5646640abae282b9093515333: {'project_id':
u'9c011aa5646640abae282b9093515333'} reserve
/opt/stack/nova/nova/quota.py:559

You can see within the [context] the change to using more information to
identify the user, and ids rather than name. The goal of this change
however is to ensure the context string is consistent across various
projects and is what is in place to be deployed in production systems.

As mentioned by Doug, there is an additional option to specify an
alternative format of user_identity (if necessary). However I have found to
make the message identical to historical name values, the minimum
requirements of oslo.log in nova would need to bump from 1.8.0 to 1.14.0

Ronald
__
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 scheduler startup when database is not available

[Lars Kellogg-Stedman]

I've been looking into the startup constraints involved when launching
Nova services with systemd using Type=notify (which causes systemd to
wait for an explicit notification from the service before considering
it to be "started".  Some services (e.g., nova-conductor) will happily
"start" even if the backing database is currently unavailable (and
will enter a retry loop waiting for the database).

Other services -- specifically, nova-scheduler -- will block waiting
for the database *before* providing systemd with the necessary
notification.

nova-scheduler blocks because it wants to initialize a list of
available aggregates (in scheduler.host_manager.HostManager.__init__),
which it gets by calling objects.AggregateList.get_all.

Does it make sense to block service startup at this stage?  The
database disappearing during runtime isn't a hard error -- we will
retry and reconnect when it comes back -- so should the same situation
at startup be a hard error?  As an operator, I am more interested in
"did my configuration files parse correctly?" at startup, and would
generally prefer the service to start (and permit any dependent
services to start) even when the database isn't up (because that's
probably a situation of which I am already aware).

It would be relatively easy to have the scheduler lazy-load the list
of aggregates on first references, rather than at __init__.  I'm not
familiar enough with the nova code to know if there would be any
undesirable implications of this behavior.  We're already punting
initializing the list of instances to an asynchronous task in order to
avoid blocking service startup.

Does it make sense to permit nova-scheduler to complete service
startup in the absence of the database (and then retry the connection
in the background)?

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/



signature.asc
Description: PGP 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

Re: [openstack-dev] [Fuel][Multirack] Are we going to support Ceph Multirack deployments?

[Aleksandr Didenko]

Hi,

just finished deployment of multirack env with ceph and external LB (not a
standard multi-rack deployment scheme, actually, but still):

http://paste.openstack.org/show/482610/

As you can see it works just fine in multirack.

Also, we're running 'deploy_ceph_ha_nodegroups' system test as a part of
'thread_7' group in our swarm tests, so ceph in multirack is covered with
automated tests as well.

Regards,
Alex

On Wed, Dec 23, 2015 at 5:29 PM, Roman Sokolkov 
wrote:

> + Konstantin and Alex
>
> Can someone give a quick highlight on that question?
>
> On Tue, Dec 22, 2015 at 8:17 PM, Roman Sokolkov 
> wrote:
>
>> Folks,
>>
>> multirack is going to be a part of MOS 8.0.
>>
>> But i can not find any info about Ceph?
>>
>> Technically Ceph supports Multiple L3 networks [1].
>>
>> [1] -
>> http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/#network-config-settings
>>
>> --
>> Roman Sokolkov,
>> Deployment Engineer,
>> Mirantis, Inc.
>> Skype rsokolkov,
>> rsokol...@mirantis.com
>>
>
>
>
> --
> Roman Sokolkov,
> Deployment Engineer,
> Mirantis, Inc.
> Skype rsokolkov,
> rsokol...@mirantis.com
>
__
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] Is Swift a good choice of database for the TripleO API?

[Ben Nemec]

On 12/23/2015 10:26 AM, Steven Hardy wrote:
> On Wed, Dec 23, 2015 at 09:28:59AM -0600, Ben Nemec wrote:
>> On 12/23/2015 03:19 AM, Dougal Matthews wrote:
>>>
>>>
>>> On 22 December 2015 at 17:59, Ben Nemec >> > wrote:
>>>
>>> Can we just do git like I've been suggesting all along? ;-)
>>>
>>> More serious discussion inline. :-)
>>>
>>> On 12/22/2015 09:36 AM, Dougal Matthews wrote:
>>> > Hi all,
>>> >
>>> > This topic came up in the 2015-12-15 meeting[1], and again briefly
>>> today.
>>> > After working with the code that came out of the deployment library
>>> > spec[2] I
>>> > had some concerns with how we are storing the templates.
>>> >
>>> > Simply put, when we are dealing with 100+ files from
>>> tripleo-heat-templates
>>> > how can we ensure consistency in Swift without any atomicity or
>>> > transactions.
>>> > I think this is best explained with a couple of examples.
>>> >
>>> >  - When we create a new deployment plan (upload all the templates
>>> to swift)
>>> >how do we handle the case where there is an error? For example,
>>> if we are
>>> >uploading 10 files - what do we do if the 5th one fails for
>>> some reason?
>>> >There is a patch to do a manual rollback[3], but I have
>>> concerns about
>>> >doing this in Python. If Swift is completely inaccessible for a
>>> short
>>> >period the rollback wont work either.
>>> >
>>> >  - When deploying to Heat, we need to download all the YAML files from
>>> > Swift.
>>> >This can take a couple of seconds. What happens if somebody
>>> starts to
>>> >upload a new version of the plan in the middle? We could end up
>>> trying to
>>> >deploy half old and half new files. We wouldn't have a
>>> consistent view of
>>> >the database.
>>> >
>>> > We had a few suggestions in the meeting:
>>> >
>>> >  - Add a locking mechanism. I would be concerned about deadlocks or
>>> > having to
>>> >lock for the full duration of a deploy.
>>>
>>> There should be no need to lock the plan for the entire deploy.  It's
>>> not like we're re-reading the templates at the end of the deploy today.
>>>  It's a one-shot read and then the plan could be unlocked, at least as
>>> far as I know.
>>>
>>>
>>> Good point. That would be holding the lock for longer than we need.
>>>  
>>>
>>> The only option where we wouldn't need locking at all is the
>>> read-copy-update model Clint mentions, which might be a valid option as
>>> well.  Whatever we do, there are going to be concurrency issues though.
>>>  For example, what happens if two users try to make updates to the plan
>>> at the same time?  If you don't either merge the changes or disallow one
>>> of them completely then one user's changes might be lost.
>>>
>>> TBH, this is further convincing me that we should just make this git
>>> backed and let git handle the merging and conflict resolution (never
>>> mind the fact that it gets us a well-understood version control system
>>> for "free").  For updates that don't conflict with other changes, git
>>> can merge them automatically, but for merge conflicts you just return a
>>> rebase error to the user and make them resolve it.  I have a feeling
>>> this is the behavior we'll converge on eventually anyway, and rather
>>> than reimplement git, let's just use the real thing.
>>>
>>>
>>> I'd be curious to hear more how you would go about doing this with git. I've
>>> never automated git to this level, so I am concerned about what issues we
>>> might hit.
>>
>> TBH I haven't thought it through to that extent yet.  I'm mostly
>> suggesting it because it seems like a fit for the template storage
>> requirements - we know we want version control, we want to be able to
>> merge changes from multiple sources, and we want some way to handle
>> merge conflicts.  Git does all of this already.
>>
>> That said, I'm not sure about everything here.  For example, how would
>> you expose merge conflicts to the user?  I don't know that I would want
>> to force a user to learn git in order to use TripleO (although that
>> would be the devops-y thing to do), but maybe just passing them back the
>> files with the merge conflict markers and having them resolve those
>> locally and retry the update would work.  I'm not sure how that would
>> map to the current version of the API though.  Do we provide any way to
>> pass templates back to the user?  I feel like that was kind of a one-way
>> street.
> 
> What part of the deployment API workflow could result in merge conflicts?
> 
> My understanding was that it's something like:
> 
> 1. Take copy of reference templates tree
> 2. Introspect tempalates, expose required parameters so user can be
> prompted for them
> 3. Create 

Re: [openstack-dev] [Fuel] Nominate Artem Panchenko for fuel-qa core

[Igor Kalnitsky]

Artem is doing a great job! Definitely +1.

On Wed, Dec 23, 2015 at 4:33 PM, Bulat Gaifullin
 wrote:
> +1
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 23 Dec 2015, at 17:29, Aleksey Kasatkin  wrote:
>
> +1
>
> Aleksey Kasatkin
>
>
> On Wed, Dec 23, 2015 at 3:57 PM, Aleksandr Didenko 
> wrote:
>>
>> +1
>>
>> On Wed, Dec 23, 2015 at 2:52 PM, Tatyana Leontovich
>>  wrote:
>>>
>>> Absolutely agree
>>>
>>> +1
>>>
>>>
>>>
>>>
>>> On Wed, Dec 23, 2015 at 3:42 PM, Andrey Sledzinskiy
>>>  wrote:

 Hi guys,
 I'd like to nominate Artem Panchenko [0] for fuel-qa core.

 Artem has great technical expertise in fuel-qa and he developed a lot of
 vital parts of framework. His first place in a number of commits is a good
 proof of that.
 His reviews are always thorough and consistent.
 Please, vote for Artem!

 [0]
 http://stackalytics.com/?user_id=apanchenko-8=all_type=all=fuel-qa

 --
 Thanks,
 Andrey Sledzinskiy
 QA Engineer,
 Mirantis, Kharkiv


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

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

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

Re: [openstack-dev] New things in Gerrit 2.11 to enjoy

[Adam Young]

On 12/22/2015 11:48 AM, Adam Young wrote:

On 12/17/2015 01:44 PM, Sean Dague wrote:

While I realize there is some sentiment about people not liking the UI
changes in Gerrit 2.11, I thought I'd provide you with some reasons to
like new gerrit.

New Search Strings:

* patch size

delta:<=10 - show only patches with <= 10 lines of change

* scoring by group

label:Code-Review<=-1,nova-core

you can now search scores by a group, so that if you are -1 filtering,
you are only doing it from the core team, so that new folks -1ing things
don't take it off your radar.

* message:/comment: queries actually work now with more than one word.


New UI features:

There is a separate Mergable field (is:mergable) which lets you know
that the code in question is no longer mergable with master.

The column 3 on the change page includes the following:

* Related Changes - all changes in the linear patch series

* Conflicts With - all open patches in the system that will conflict
with this one

This is great for discovering duplicates for the same fix.

* Same topic - anything with the same topic, again for group reviewing.


Inline Edit:

You can now inline edit the entire patch. Click the Edit button above
the list of files, and you go into edit mode, and can fix the commit
message or any files. This pops you into a separate screen where you
'Save' the change, then eventually "Publish Edit" on the main page.


Gah so close.  The implementation does not work with how code review 
is done;


If you click edit, you do not see comments.
It is a full different page.

And...now I see the real deal:

Once a comment has been submitted, you can click "fix" and get the edit 
view.   This is very powerful...excellent.





If a reviewer could trivially change "Gald" to "Glad" inline, it would 
be worthwhile.


So.Dang.Close.

I wonder how we can close the gap on this?




There is also the "Follow Up" button where it builds you an empty follow
up patch that you can inline edit to fix something. Especially good if
you want to just follow up with a typo fix.


Yes, a lot of the UI elements move around from the old change screen
(even from the new one in old gerrit), so there will be some getting
used to. However a lot of these new features are quite nice for
increasing review productivity once you get used to some of the new 
widgets.



-Sean






__
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] [devstack][QA] Changing logging format to match documented defaults

[Doug Hellmann]

Excerpts from Ronald Bradford's message of 2015-12-23 12:57:07 -0500:
> Ian,
> 
> On Tue, Dec 22, 2015 at 3:22 PM, Ian Wienand  wrote:
> >
> > On 12/23/2015 05:55 AM, Ronald Bradford wrote:
> > > I have observed that devstack uses custom logging formatting that
> > > differs from the documented defaults. An example is for nova.  which
> > > is defined in [1]
> >
> > The original point mentioned there of using "*_name" for extra
> > verbosity still seems relevant [1]
> >
> > > logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
> > > %(name)s [%(request_id)s *%(user_identity)s*] %(instance)s%(message)s
> >
> > user_identity is still just "{user} {tenant} ..." (which is id's, I
> > believe?) [2].
> 
> 
> For reference, here are messages using before and after suggestions with
> and without context. Presently, the default value defines 5 distinct
> components including user and tenant/project.
> 
> Before:
> 
> 2015-12-18 18:22:52.788 DEBUG oslo_concurrency.lockutils
> [*req-bcd393ce-523e-454e-b05a-7b80f82aaaf0
> None None*] Acquired semaphore "singleton_lock" lock
> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:197
> 
> 2015-12-23 17:21:12.570 DEBUG nova.quota
> [*req-a65d797f-1e7e-48b4-a0b7-92f48e5f6bcd
> admin demo*] Quota limits for project 9c011aa5646640abae282b9093515333:
> {'project_id': u'9c011aa5646640abae282b9093515333'} reserve
> /opt/stack/nova/nova/quota.py:559
> 
> After:
> 
> 2015-12-18 18:28:10.890 DEBUG oslo_concurrency.lockutils
> [*req-2d7df976-5004-4da2-83cc-2ed96ee42049
> - - - - -*] Acquired semaphore "singleton_lock" lock
> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:197
> 
> 2015-12-23 17:24:44.228 11197 DEBUG nova.quota
> [*req-bfc10adf-5a05-4fd1-a671-32547f48f391
> bc455368223742729898fb85c995694d 9c011aa5646640abae282b9093515333 - - -*]
> Quota limits for project 9c011aa5646640abae282b9093515333: {'project_id':
> u'9c011aa5646640abae282b9093515333'} reserve
> /opt/stack/nova/nova/quota.py:559
> 
> You can see within the [context] the change to using more information to
> identify the user, and ids rather than name. The goal of this change
> however is to ensure the context string is consistent across various
> projects and is what is in place to be deployed in production systems.
> 
> As mentioned by Doug, there is an additional option to specify an
> alternative format of user_identity (if necessary). However I have found to
> make the message identical to historical name values, the minimum
> requirements of oslo.log in nova would need to bump from 1.8.0 to 1.14.0

It's currently 1.12.0, according to
http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n95

If we need to ensure that a new feature is present, we can raise that
minimum by patching that global-requirements.txt file and then letting
the bot propose the changes to all of the projects.

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] [mistral] [murano] [yaql] An online YAQL evaluator [was RE: [mistral] [murano] An online YAQL evaluator]

[Lingxian Kong]

Hi, Moshe,

Really amazing work! Thanks for the efforts from you guys!

On Wed, Dec 23, 2015 at 1:06 AM, ELISHA, Moshe (Moshe)
 wrote:
> Hi all,
>
>
>
> Thank you for the kind words.
>
> Just wanted to let you know that yaqluator[1] was updated and now supports
> YAQL 1.0.2.
>
> There is also a checkbox there to work in “Legacy Mode”.
>
>
>
> Hope you will find it useful.
>
>
>
> [1] http://yaqluator.com/
>
>
>
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Friday, August 14, 2015 11:51 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [mistral] [murano] An online YAQL evaluator
>
>
>
> I just read this thread so decided to add my 2 cents into the collection of
> opinions.
>
>
>
> Guys, I tried it out a couple of weeks ago (was told about it by one of my
> colleagues). This is really incredible! Especially given that you completed
> it in 24 hours :) I think as YAQL attracts more and more users it will be
> very handy tool. I am actually for improving it further.
>
>
>
> Thanks a lot! Looking forward to switch to yaql 1.0!
>
>
>
> Renat Akhmerov
>
> @ Mirantis Inc.
>
>
>
>
>
>
>
> On 05 Aug 2015, at 04:09, Stan Lagun  wrote:
>
>
>
> Dmitry,
>
>
>
> yaql 1.0 has both str() and len() and much much more so there is no need to
> support them explicitly since Mistral is going to switch to yaql 1.0 and
> yaqluator.com is going to do the same
>
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
>
>
>
> On Tue, Aug 4, 2015 at 8:55 PM, Dmitri Zimine 
> wrote:
>
> Awesome! Really.
>
>
>
> Thank you folks for doing this.
>
>
>
> I am so much looking forward to moving it to 1.0 with more built-in
> functions and more power to extend it...
>
>
>
> Note that Mistral has a few extensions, like `str`, `len`, which are not in
> the scope of evaluator.
>
>
>
> DZ>
>
>
>
>
>
> On Aug 2, 2015, at 12:44 PM, Stan Lagun  wrote:
>
>
>
> Guys, this is awesome!!!
>
>
>
> Happy to see yaql gets attention. One more initiative that you may find
> interesting is https://review.openstack.org/#/c/159905/
>
> This is an attempt to port yaql 1.0 from Python to JS so that the same can
> be done in browser
>
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
>
>
>
> On Sun, Aug 2, 2015 at 5:30 PM, Nikolay Makhotkin 
> wrote:
>
> Hi guys!
>
>
>
> That's awesome! It is very useful for all us!
>
>
>
> --
>
> Best Regards,
>
> Nikolay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack 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
>



-- 
Regards!
---
Lingxian Kong

__
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] [magnum] Mesos Conductor patch for review

[bharath thiruveedula]

Hi,As per the discussion in [1], I have pushed patchset [1]. Can you please 
review  the patch. I want to take comments on this patch before I push test 
cases and container-list operation because there was a discussion on this topic 
whether to have this or not. (from my previous experience :) ). RegardsBharath 
T[1]http://lists.openstack.org/pipermail/openstack-dev/2015-December/081818.html[2]https://review.openstack.org/#/c/258860/
__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Carl Baldwin]

On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko  wrote:
> n goes to next occurrence and N (shift+n) to a previous one. These are
> same keybindings as in Vim. Actually a lot of Vim-like movements are
> functional in new Gerrit and I really like that fact.

Thanks.  Looking again, I see that the help for 'n' does hint at that.
It is a strange overloading of the key binding because then navigating
comments no longer seems to work after I start searching.  How could I
go back to navigating comments?  I tried hitting '/' again and the ESC
to cancel searching but the comment navigation doesn't always come
back.

I do see that a lot of vim movement does work.  I was hoping that
holding down a movement command like 'j' would rapidly move down but
it doesn't.  :(

Carl

__
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] [infra][release][all] Automatic .ics generation for OpenStack's and project's deadlines

[Louis Taylor]

On Wed, Dec 23, 2015 at 2:26 PM, Doug Hellmann  wrote:
> What you have is a really good start. Thanks for working on this!
> How do you feel about importing the repository into gerrit?
>
> A couple of things I'd like to see added:
>
> 1. Separate sections for cross-project and project-specific events.
>
>This would let us completely generate the RST content, as it
>appears on http://docs.openstack.org/releases/schedules/mitaka.html,
>as well as generate project-specific ICS files (some folks may want
>to only subscribe to cross-project events and their own project's
>schedule).
>
> 2. Durations for individual events.
>
>This would let us have single-day events, such as the final
>release date, as well as include things like mid-cycle meetings,
>sprints, etc. that may not all last 4 days.
>
> 3. The "generator" python package directory will probably need to
>be renamed to something more descriptive to let this be installed
>with other projects, which we'll need in order to integrate it with
>Sphinx.
>
> 4. That Sphinx integration will be easier if the function to construct
>the data structure representing the schedule data is separated from
>the function to format the data in different ways. That's just
>refactoring some of what's already there, so it's not a big deal.
>
> Doug

Hi Doug, thanks for the feedback!

I'll import this into gerrit and have a look at working on your suggestions.

Cheers,
Louis

__
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 scheduler startup when database is not available

[Mike Bayer]

On 12/23/2015 01:32 PM, Jay Pipes wrote:
> On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote:
>> I've been looking into the startup constraints involved when launching
>> Nova services with systemd using Type=notify (which causes systemd to
>> wait for an explicit notification from the service before considering
>> it to be "started".  Some services (e.g., nova-conductor) will happily
>> "start" even if the backing database is currently unavailable (and
>> will enter a retry loop waiting for the database).
>>
>> Other services -- specifically, nova-scheduler -- will block waiting
>> for the database *before* providing systemd with the necessary
>> notification.
>>
>> nova-scheduler blocks because it wants to initialize a list of
>> available aggregates (in scheduler.host_manager.HostManager.__init__),
>> which it gets by calling objects.AggregateList.get_all.
>>
>> Does it make sense to block service startup at this stage?  The
>> database disappearing during runtime isn't a hard error -- we will
>> retry and reconnect when it comes back -- so should the same situation
>> at startup be a hard error?  As an operator, I am more interested in
>> "did my configuration files parse correctly?" at startup, and would
>> generally prefer the service to start (and permit any dependent
>> services to start) even when the database isn't up (because that's
>> probably a situation of which I am already aware).
> 
> If your configuration file parsed correctly but has the wrong database
> connection URI, what good is the service in an active state? It won't be
> able to do anything at all.

this is true, but to be fair, Nova doesn't work like this at all, at
least not in nova/db/sqlalchemy/api.py.  It is very intentionally
designed to *not* connect to the database until an API call is first
accessed, to the extent that it does an end-run around oslo.db's
create_engine() feature which itself does a "test" connection when it is
called (FTR, SQLAlchemy's create_engine() that is called by oslo.db is
in fact a lazy-initializing function).I find it quite awkward
overall that oslo.db reverses SQLAlchemy's "lazyness", but then nova and
others re-reverse *back* to "lazyness", but at the expense of allowing
oslo.db's create_engine() to receive its configuration up front.

In the reworked enginefacade API I went through a lot of effort to
replicate this behavior.   It would be nice if all Openstack apps could
just pick one paradigm and stick with it so that we can just make
oslo.db do *one* pattern and that's all (probably too late though).


> 
> This is why I think it's better to have hard checks like for connections
> on startup and not have services active if they won't be able to do
> anything useful.
> 
>> It would be relatively easy to have the scheduler lazy-load the list
>> of aggregates on first references, rather than at __init__.
> 
> Sure, but if the root cause of the issue is a problem due to
> misconfigured connection string, then that lazy-load will just bomb out
> and the scheduler will be useless anyway. I'd rather have a
> fail-early/fast occur here than a fail-late.
> 
> Best,
> -jay
> 
>> I'm not
>> familiar enough with the nova code to know if there would be any
>> undesirable implications of this behavior.  We're already punting
>> initializing the list of instances to an asynchronous task in order to
>> avoid blocking service startup.
>>
>> Does it make sense to permit nova-scheduler to complete service
>> startup in the absence of the database (and then retry the connection
>> in the background)?
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] glance details

[葛志伟]

I can not find the keyword 'checksum' when I type "glance details".how to modify__
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 scheduler startup when database is not available

[Morgan Fainberg]

On Wed, Dec 23, 2015 at 10:32 AM, Jay Pipes  wrote:

> On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote:
>
>> I've been looking into the startup constraints involved when launching
>> Nova services with systemd using Type=notify (which causes systemd to
>> wait for an explicit notification from the service before considering
>> it to be "started".  Some services (e.g., nova-conductor) will happily
>> "start" even if the backing database is currently unavailable (and
>> will enter a retry loop waiting for the database).
>>
>> Other services -- specifically, nova-scheduler -- will block waiting
>> for the database *before* providing systemd with the necessary
>> notification.
>>
>> nova-scheduler blocks because it wants to initialize a list of
>> available aggregates (in scheduler.host_manager.HostManager.__init__),
>> which it gets by calling objects.AggregateList.get_all.
>>
>> Does it make sense to block service startup at this stage?  The
>> database disappearing during runtime isn't a hard error -- we will
>> retry and reconnect when it comes back -- so should the same situation
>> at startup be a hard error?  As an operator, I am more interested in
>> "did my configuration files parse correctly?" at startup, and would
>> generally prefer the service to start (and permit any dependent
>> services to start) even when the database isn't up (because that's
>> probably a situation of which I am already aware).
>>
>
> If your configuration file parsed correctly but has the wrong database
> connection URI, what good is the service in an active state? It won't be
> able to do anything at all.
>
> This is why I think it's better to have hard checks like for connections
> on startup and not have services active if they won't be able to do
> anything useful.
>
>
Are you advocating that scheduler bails out and ceases to run or that it
doesn't mark itself as active? I am in favour of the second scenario but
not the first. There are cases where it would be nice to start the
scheduler and have it at least report "hey I can't contact the DB" but not
mark itself active, but continue to run and on  report/try to
reconnect.

It isn't clear which level of "hard check" you're advocating in your
response and I want to clarify for the sake of conversation.


> It would be relatively easy to have the scheduler lazy-load the list
>> of aggregates on first references, rather than at __init__.
>>
>
> Sure, but if the root cause of the issue is a problem due to misconfigured
> connection string, then that lazy-load will just bomb out and the scheduler
> will be useless anyway. I'd rather have a fail-early/fast occur here than a
> fail-late.
>
> Best,
> -jay
>
> > I'm not
>
>> familiar enough with the nova code to know if there would be any
>> undesirable implications of this behavior.  We're already punting
>> initializing the list of instances to an asynchronous task in order to
>> avoid blocking service startup.
>>
>> Does it make sense to permit nova-scheduler to complete service
>> startup in the absence of the database (and then retry the connection
>> in the background)?
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Merge Freeze for cutting stable/8.0 branch

[Aleksandra Fedorova]

Hi, here is the status update:

- we created stable/8.0 branch in all repositories;
- Fuel CI [1] is updated with 8.0 triggers and jobs, fuel-library
tests are working on pre-SCF ISO image still;
- 8.0 ISO builds are switched to stable/8.0 branch, see [2] for the first run;
- development focus in Launchpad has been switched to mitaka(9.0) series [3]

If you file a bug for 8.0 release, please make sure you explicitly
target it to 8.0.x series additionally to the mitaka series which it
gets by default.

Remaining tasks:

  due to several issues caused by pre-SCF merge rush, we don't yet
have a working ISO for version bumps patches [4]

Therefore we are still in Merge Freeze, as we need to stabilize master
before moving forward.

Latest blocker for the merge - inconsistent 9.0 mirrors. Build team
will look into it, and I'll post an update with more information.

[1] https://ci.fuel-infra.org
[2] https://ci.fuel-infra.org/view/ISO/job/8.0-community.all/185/console
[3] https://launchpad.net/fuel/mitaka
[4] https://review.openstack.org/#/q/topic:8.0-scf

On Wed, Dec 23, 2015 at 10:48 AM, Aleksandra Fedorova
 wrote:
> Hi Fuelers,
>
> SCF has been declared [1] and we start creating stable/8.0 branch in
> all projects.
>
> Please don't merge anything both to master and to stable/8.0 until we
> verify Infra and CI readiness.
>
> List of projects affected:
>
>   fuel-main
>   fuel-agent
>   fuel-astute
>   fuel-library
>   fuel-menu
>   fuel-ostf
>   fuel-qa
>   fuel-upgrade
>   fuel-web
>   shotgun
>   python-fuelclient
>   network-checker
>   fuel-nailgun-agent
>   fuel-mirror
>
> Use #fuel-infra or #fuel-dev IRC channels for questions.
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082939.html
>
> --
> Aleksandra Fedorova
> Fuel CI Team Lead
> bookwar



-- 
Aleksandra Fedorova
CI Team Lead
bookwar

__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Clark Boylan]

On Wed, Dec 23, 2015, at 03:00 PM, Carl Baldwin wrote:
> On Wed, Dec 23, 2015 at 3:40 PM, Zaro  wrote:
> > On Tue, Dec 22, 2015 at 4:51 PM, Carl Baldwin  wrote:
> >> I noticed another thing.  I'm working with a chain of three patches.
> >> I just updated the patch in the middle [1] to patch set 37.  I noticed
> >> that the list of "Related Changes" (in the upper right of the page)
> >> didn't look right.  The change above it in the list (the one that
> >> depends it) looked strange.  Looking closer, I realized that the
> >> dependent patch was linking to patch set 4 [2] which is really old.
> >> Go here [1] and take a look.
> >>
> >> The latest patch set in 212669 (24) depends on a slightly out of date
> >> version of 192032 (36 of 37).  So, gerrit decides to navigate me to
> >> version 4 of 212669?  Seems arbitrary to me.  Why doesn't it navigate
> >> me to the latest version of 212669?  That would be much more useful.
> >
> > I believe what Gerrit is doing is linking to the PS that was based off
> > of the one you are currently on.  You can see this by checking the
> > parent and next commit SHA.  So it looks like 212669/4 is based on
> > 192032/10 therefore I'm guessing that you were actually looking at
> > 192032/10 when you clicked on the link.  I'm not sure that Gerrit took
> > you to the wrong PS I'm guessing that you were on a newer 212669 PS
> > than you thought?   I find this disorienting as well and always have
> > to remind myself to look at the "Patch Sets" indicator to get on the
> > right page.
> 
> No, I was looking at PS37 of 192032.  Exactly the patch set that I
> linked to.  I just checked again by click on the link [1] and looking
> at the related changes in the upper right corner.  Do it.  What patch
> set of change 212669 do you see linked from here [1]?  If you are not
> seeing 212669/4 , then you are seeing something different than I am.
> It isn't only disorienting.  IMO, it is wrong.
> 
> >> [1] https://review.openstack.org/#/c/192032/37
> >> [2] https://review.openstack.org/#/c/212669/4
> 
I got curious and this is an odd situation. I can't find where 212669
has a patchset with a parent of the commit for 192032,37 (b7151e4). Git
represents the tree as a DAG with each child commit pointing at its
parent(s). Parents do not know who their children are. When 212669 has a
patchset with a parent that maps to a valid 192032 patchset everything
works (see 212669,30 and 192032,36 for example) but when 192032 has a
patchset with no children in 212669 it gets confused.

This makes some sense given Git's internal DAG. Gerrit knows 212669 is
related to 192032 via the other patchsets, but it can't associate to a
specific patchset. I am not sure yet if the selection of patchset 4 is
intentional design and does something that would make sense if I
understood it better or if it is a bug in a best effort approach. The
most correct thing to do would be for 192032,37 to not show any
association to 212669 since there doesn't exist a Git DAG with that
relationship.

Clark

__
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][keystone] how to reauth the token

[Adam Young]

On 12/16/2015 01:59 PM, Clint Byrum wrote:

Excerpts from Pavlo Shchelokovskyy's message of 2015-12-16 07:59:42 -0800:

Hi all,

I'd like to start discussion on how Ironic is using Neutron when Keystone
is involved.

Recently the patch [0] was merged in Ironic to fix a bug when the token
with which to create the neutronclient is expired. For that Ironic now
passes both username/password of its own service user and the token from
the request to the client. But that IMO is a wrong thing to do.

When token is given but happens to be expired, neutronclient will
reauthentificate [1] using provided credentials for service tenant and user
- but in fact the original token might have come from completely different
tenant. Thus the action neutron is performing might look for / change
resources in the service tenant instead of the tenant for which the
original token was issued.

Ironic by default is admin-only service, so the token that is accepted is
admin-scoped, but still it might be coming from different tenants (e.g.
service tenant or actual admin tenant, or some other tenant that admin is
logged into). And even in the case of admin-scoped token I'm not sure how
this will work for domain-separated tenants in Keystone v3. Does
admin-scoped neutronclient show all ports including those created by
tenants in domains other than the domain of admin tenant?

If I understand it right, the best we could do is use keystoneauth *token
auth plugins that can reauth when the token is about to expire (but of
course not when it is already expired).

Why not use trusts the way Heat does?


Too Heavyweight to create a trust for every request.  Better to make the 
Neutron user a trusted user and let the service do the operation implicitly.




__
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] [puppet] adding puppet-rally to OpenStack

[Andy Botting]

Hi Emilien,


> Emilien Macchi wrote:
> > I just noticed we have a second module written by Cody:
> > https://github.com/ody/puppet-rally
> >
> > We might want to collaborate on that.
> >
>
> Yeah...I'd actually completely forgotten that existed until Emilien
> mentioned it to me in IRC.
>
> It was my responsibility to deploy rally for our production cloud so I
> started down the road of building a rally module that I intended to ship
> upstream but things never panned out.  I pretty much ran cookiecutter
> and then added the openstack-rally package resource that was dependent
> on our internal RPM repository that contained a openstack-rally package
> I built myself because one existed no where else.  I never actually ran
> the module through Puppet.
>
> Since we were behind on deployment I put rally on the back burner until
> I had something fully functional in pre-production to start running
> rally against.  Plus, at that time we were pre-liberty release so no one
> was shipping an openstack-rally package which would have made putting
> the module I started into the upstream project difficult since it would
> be unusable and untestable.  So, instead I focussed on tying off some
> other internal things and my OpenStack time was spent working on already
> established Puppet OpenStack community items, reviews and CI.
>
> Now we are in December and Mitaka is in full swing, there are
> openstack-rally packages upstream in Mitaka repos, and our internal
> pre-production install is fully functional so...I am back to working on
> a rally deployment.  I am happy to collaborate on merging/just promoting
> one of these modules to upstream.  I do not have a preference for which
> one does become upstream; in their current state they probably both need
> a fresh run through cookiecutter and msync


As discussed on IRC, I've started a new puppet-rally module:

https://github.com/andybotting/puppet-rally

It's based on a fresh run of cookiecutter/msync and it's fairly complete.
There's a few tests in there, but they're failing due to not being able to
find an official rally package.

When I'm back at work in the new year, I'll be looking to switch our
production system over to this new module to test it.

Rally has a lot of config options, so I wrote a hacky script to pull all
the options from the default rally.conf file and use them in the module. It
makes the init.pp params pretty long. I thought an alternative could have
been to pass in a hash of override params, but I prefer it this way TBH.

Let me know what you think.

cheers,
Andy
__
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] [fuel] RabbitMQ in dedicated network

[Vladimir Kuklin]

Kyrylo

One comment here. Hostname on the nodes resolves to its management network
as it is put into /etc/hosts file during the deployment.

On Wed, Dec 23, 2015 at 9:27 PM, Alexey Lebedeff 
wrote:

>
> When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME
> environment variable), you could actually use IP-address as a node name.
>
> Matthew Mosesohn writes:
>
> > I agree. As far as I remember, rabbit needs fqdns to work and map
> > correctly. I think it means we should disable the ability to move the
> > internal messaging network role in order to fix this bug until we can add
> > extra dns entries per network role (or at least addr)
> > On Dec 23, 2015 8:42 PM, "Andrew Maksimov" 
> wrote:
> >
> >> Hi Kirill,
> >>
> >> I don't think we can give up on using fqdn node names for RabbitMQ
> because
> >> we need to support TLS in the future.
> >>
> >> Thanks,
> >> Andrey Maximov
> >> Fuel Project Manager
> >>
> >> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov 
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> I would like to start discussion regarding the issue we have discovered
> >>> recently [1].
> >>>
> >>> In a nutshell, if RabbitMQ is configured to run in separate
> >>> mgmt/messaging network it fails on building cluster.
> >>> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is
> >>> built using FQDN. Apparently, FQDN resolves to admin network which is
> >>> different in this particular case.
> >>> As a result, RabbitMQ on secondary controller node fails to join to
> >>> primary controller node.
> >>>
> >>> I can suggest two ways to tackle the issue: one is pretty simple, while
> >>> other is not.
> >>>
> >>> The first way is to accept by design using admin network for RabbitMQ
> >>> internal communication between controller nodes.
> >>>
> >>> The second way is to dig into pacemaker and RabbitMQ reconfiguration.
> >>> Since it requires to refuse from using common fqdn/node names, this
> >>> approach can be argued.
> >>>
> >>>
> >>> --
> >>> [1] https://bugs.launchpad.net/fuel/+bug/1528707
> >>>
> >>> Best regards,
> >>> Kyrylo
>
> __
> 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
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Carl Baldwin]

On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko  wrote:
> n goes to next occurrence and N (shift+n) to a previous one. These are
> same keybindings as in Vim. Actually a lot of Vim-like movements are
> functional in new Gerrit and I really like that fact.

I'll admit that I started to get excited about the vim-like movements.
My fingers know them pretty well.  But, now this new interface is
driving me even more crazy!  Here's why:

Things like 'v' works to highlight parts of the code.  I found the
following all worked:  'b', 'w', 'h', 'l', '400G', and some more.
But, then my fingers started doing things that ended up sending me all
over the place.  For example, after discovering that 'b' and 'w' work,
you'd expect 'e' to work similarly.  Nope, that throws you in the
editor (which I'm not nearly as excited about as everyone else seems
to be).  Then, I tried 'fM' to put the cursor on the next occurrence
of 'M'.  I have no idea why but I ended up in a different file
altogether.  There were a couple others that I didn't take careful
note of but this afternoon trying out vim keys has been a disaster.

The problem here is that I've been a vi(m) user since high school.  I
don't think about the navigation commands, they are all in muscle
memory.  So, to start using vim muscle memory at all in gerrit is
dangerous.  Who knows what is going to happen because they only
partially (and apparently arbitrarily) implemented the movement
commands and didn't document which ones work and which ones to watch
out for because they have a different meaning in gerrit.

So, the end result is that I'm learning a whole new way of navigating
without the proper documentation to help.

Carl

__
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] [puppet] cleanup warnings

[Emilien Macchi]

Hi,

I'm working on cleaning-up some warnings that we have when deploying with
default values in our manifests (what our CI is supposed to do when
possible).

Here is a list of bugs / patches in progress to drop the warnings:

https://bugs.launchpad.net/puppet-nova/+bug/1506066
https://bugs.launchpad.net/bugs/1528963
https://bugs.launchpad.net/bugs/1528964
https://bugs.launchpad.net/puppet-vswitch/+bug/1524559
https://review.openstack.org/261121
https://review.openstack.org/261119
https://review.openstack.org/261105

(I might have missed some of them)

If you're interested to help, by reviewing or even doing code, please go
ahead,
Thanks,
-- 
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-dev] [Fuel] Spec policy

[Andrew Woodward]

We've been developing following the spec and blueprint approach for a while
and have even been firm with requiring "blueprint or bug" on commit
messages for a while now. However we have been more than neglecting the
specification ('spec') process. Quite often we see that a spec languishes
on review, sometimes its not reviewed, others it's not updated by the
other. In the end, its common that code lands in the component prior to the
spec being completed and merged its self. Furthermore this results in late
management of the blueprints in launchpad.

I propose that we start enforcing the implied spec requirement. At the same
time, we should be managing the blueprint status along with the spec so
that reviewers can quickly identify the status of the blueprint. Lastly, we
will need to clarify the role of the spec on the wiki as it's currently not
clear.


-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

[Elizabeth K. Joseph]

On Wed, Dec 23, 2015 at 10:11 AM, Carl Baldwin  wrote:
> I do see that a lot of vim movement does work.  I was hoping that
> holding down a movement command like 'j' would rapidly move down but
> it doesn't.  :(

Earlier in the thread zaro mentioned this in passing, but to be more
specific: hitting '?' will bring up a menu of keyboard shortcuts that
can be used. This works in various screens throughout the Gerrit web
UI. No guessing required as to what shortcuts exist or how they work.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Carl Baldwin]

On Wed, Dec 23, 2015 at 3:40 PM, Zaro  wrote:
> On Tue, Dec 22, 2015 at 4:51 PM, Carl Baldwin  wrote:
>> I noticed another thing.  I'm working with a chain of three patches.
>> I just updated the patch in the middle [1] to patch set 37.  I noticed
>> that the list of "Related Changes" (in the upper right of the page)
>> didn't look right.  The change above it in the list (the one that
>> depends it) looked strange.  Looking closer, I realized that the
>> dependent patch was linking to patch set 4 [2] which is really old.
>> Go here [1] and take a look.
>>
>> The latest patch set in 212669 (24) depends on a slightly out of date
>> version of 192032 (36 of 37).  So, gerrit decides to navigate me to
>> version 4 of 212669?  Seems arbitrary to me.  Why doesn't it navigate
>> me to the latest version of 212669?  That would be much more useful.
>
> I believe what Gerrit is doing is linking to the PS that was based off
> of the one you are currently on.  You can see this by checking the
> parent and next commit SHA.  So it looks like 212669/4 is based on
> 192032/10 therefore I'm guessing that you were actually looking at
> 192032/10 when you clicked on the link.  I'm not sure that Gerrit took
> you to the wrong PS I'm guessing that you were on a newer 212669 PS
> than you thought?   I find this disorienting as well and always have
> to remind myself to look at the "Patch Sets" indicator to get on the
> right page.

No, I was looking at PS37 of 192032.  Exactly the patch set that I
linked to.  I just checked again by click on the link [1] and looking
at the related changes in the upper right corner.  Do it.  What patch
set of change 212669 do you see linked from here [1]?  If you are not
seeing 212669/4 , then you are seeing something different than I am.
It isn't only disorienting.  IMO, it is wrong.

>> [1] https://review.openstack.org/#/c/192032/37
>> [2] https://review.openstack.org/#/c/212669/4

__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Zaro]

On Tue, Dec 22, 2015 at 4:51 PM, Carl Baldwin  wrote:
> I noticed another thing.  I'm working with a chain of three patches.
> I just updated the patch in the middle [1] to patch set 37.  I noticed
> that the list of "Related Changes" (in the upper right of the page)
> didn't look right.  The change above it in the list (the one that
> depends it) looked strange.  Looking closer, I realized that the
> dependent patch was linking to patch set 4 [2] which is really old.
> Go here [1] and take a look.
>
> The latest patch set in 212669 (24) depends on a slightly out of date
> version of 192032 (36 of 37).  So, gerrit decides to navigate me to
> version 4 of 212669?  Seems arbitrary to me.  Why doesn't it navigate
> me to the latest version of 212669?  That would be much more useful.

I believe what Gerrit is doing is linking to the PS that was based off
of the one you are currently on.  You can see this by checking the
parent and next commit SHA.  So it looks like 212669/4 is based on
192032/10 therefore I'm guessing that you were actually looking at
192032/10 when you clicked on the link.  I'm not sure that Gerrit took
you to the wrong PS I'm guessing that you were on a newer 212669 PS
than you thought?   I find this disorienting as well and always have
to remind myself to look at the "Patch Sets" indicator to get on the
right page.

>
> Over the last few days, this "Related Changes" table has confused me.
> This is the first time I took the time to pinpoint why it is confusing
> me.
>
> Carl
>
> PS  I'm trying to document these issues in this thread so that they
> don't get lost.  I suppose at some point we need to be feeding this
> stuff up to gerrit.  I was hoping to get other stuff done before
> vacation and so I'm hesitant to stop what I'm doing and shift my
> thinking toward filling out bug reports against gerrit.  What should
> we do?  Should we individually go file bugs against gerrit?  Or,
> should we funnel it through someone working on gerrit in openstack?

Thanks for keeping the openstack infra team updated about issues
you're having with Gerrit, it's good feedback and will help improve
Gerrit going forward.  Unless it's something that requires immediate
attention I would recommend entering a bug/feature request yourself on
upstream Gerrit issue tracker. You can CC me on the issues and I will
try to determine whether it's openstack specific or a general upstream
issue.

>
> [1] https://review.openstack.org/#/c/192032/37
> [2] https://review.openstack.org/#/c/212669/4
>

__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Zaro]

These look like upstream issues.  Best thing to do is report these
bugs upstream: https://code.google.com/p/gerrit/issues/list


On Tue, Dec 22, 2015 at 11:25 AM, Aishwarya Thangappa
 wrote:
> Hi there,
>
> I noticed a couple of things which I would like to see fixed.
> 1. When you try to reply to a review comment, it jumps to the previous or
> next comment and you have to scroll again to get back to it.
> 2. When you scroll down through a file, the Patch Set bar gets hidden. You
> have to scroll all the way up to see it again.
> I saw this behavior with both chrome and firefox.
>
> Aish.
>

__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Carl Baldwin]

On Wed, Dec 23, 2015 at 1:57 PM, Elizabeth K. Joseph 
wrote:
> On Wed, Dec 23, 2015 at 10:11 AM, Carl Baldwin  wrote:
>> I do see that a lot of vim movement does work. I was hoping that
>> holding down a movement command like 'j' would rapidly move down but
>> it doesn't. :(
>
> Earlier in the thread zaro mentioned this in passing, but to be more
> specific: hitting '?' will bring up a menu of keyboard shortcuts that
> can be used. This works in various screens throughout the Gerrit web
> UI. No guessing required as to what shortcuts exist or how they work.

I'm aware of the '?' help and have found it lacking. I've still had to
guess at how they work (or don't work) in some cases. For example, where
are many of the vim movement commands documented (besides j/k which I knew
about by reading the help)? I missed the navigation to the next/previous
search result because it isn't documented with shift + n but is with n. I
missed it.

And it doesn't excuse the awful overloading of n and shift + n which breaks
navigation by chunks once you start using the search feature.

I really haven't been impressed by many of the new features because they
all seem to come with awkward baggage.

Carl I
__
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] [Fuel] Nominate Artem Roma for fuel-ostf core

[Alexander Kislitsky]

+1

On Wed, Dec 23, 2015 at 8:15 PM, Aleksey Kasatkin 
wrote:

> +1
>
> Aleksey Kasatkin
>
>
> On Wed, Dec 23, 2015 at 5:28 PM, Aleksandr Didenko 
> wrote:
>
>> +1
>>
>> On Wed, Dec 23, 2015 at 4:21 PM, Andrey Sledzinskiy <
>> asledzins...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> On Wed, Dec 23, 2015 at 5:05 PM, Tatyana Leontovich <
>>> tleontov...@mirantis.com> wrote:
>>>
 Hi guys,
 I'd like to nominate Artem Roma [0] for fuel-ostf core.

 Artem  cares about fuel-ostf more then 2 years, always provide a great
 reviews(always thorough and consistent and comes in time), extend unit
 tests coverages and provide a lot of bug fixes and improvements there.

 Please, vote for Artem!


 http://stackalytics.com/?user_id=aroma-x=all_type=all=fuel-ostf


 __
 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


>>>
>>>
>>> --
>>> Thanks,
>>> Andrey Sledzinskiy
>>> QA Engineer,
>>> Mirantis, Kharkiv
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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] [openstack][magnum]Create trustee user for each bay

[王华]

Hi all,

I want to create a trustee user for each bay [1]. The discussion for trust
is in [2].

Here is my solution:
I don't create a user for each bay. All the bays no matter who creates it
use the same user.
But we create different trust for the user for different bay. The user can
not access any service without the trust id. So there is no need to create
a user for each bay.


[1]
https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay
[2]https://review.openstack.org/#/c/254705/

Regards,
Wanghua
__
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] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Duncan,

Thank you for the suggestion, will do.
On Wed, 23 Dec 2015 at 10:55, Duncan Thomas  wrote:

> On a cloud with a large number of tenants, this is going to involve a
> large number of API calls. I'd suggest you put a spec into cinder to add an
> API call for getting the totals straight out of the DB - it should be easy
> enough to add.
>
> On 18 December 2015 at 20:35, Timur Sufiev  wrote:
>
>> Matt,
>>
>> actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call
>> that I needed. Now I know how to retrieve Cinder quota usage info
>> per-tenant, seems that to retrieve the same info cloud-wide I should sum up
>> all the available tenant usages.
>>
>> With Cinder quota usages being sorted out, my next goal is Nova and
>> Neutron. As for Neutron, there are plenty of quota-related calls I'm going
>> to play with next week, perhaps there is something suitable for my use
>> case. But as for Nova, I haven't found something similar to 'usage' of
>> cinderclient call, so help from someone familiar with Nova is very
>> appreciated :).
>>
>> [0]
>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
>>
>> On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann <
>> mrie...@linux.vnet.ibm.com> wrote:
>>
>>>
>>>
>>> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
>>> > Hi Timur,
>>> >
>>> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
>>> >
>>> >
>>> >
>>> > [1]
>>> >
>>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
>>> > [2] http://paste.openstack.org/show/482225/
>>> >
>>> > Regards,
>>> > Ivan Kolodyazhny,
>>> > http://blog.e0ne.info/
>>> >
>>> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev >> > > wrote:
>>> >
>>> > Hello, folks!
>>> >
>>> > I'd like to initiate a discussion of the feature request I'm going
>>> > to make on behalf of Horizon to every core OpenStack service which
>>> > supports Quota feature, namely Cinder, Nova and Neutron.
>>> >
>>> > Although all three services' APIs support special calls to get
>>> > current quota limitations (Nova and Cinder allows to get and update
>>> > both per-tenant and default cloud-wide limitations, Neutron allows
>>> > to do it only for per-tenant limitations), there is no special call
>>> > in any of these services to get current per-tenant usage of quota.
>>> > Because of that Horizon needs to get, say for 'volumes' quota, a
>>> > list of Cinder volumes in the current tenant and then just
>>> calculate
>>> > its length [1]. When there are really a lot of entities in tenant -
>>> > instances/volumes/security groups/whatever - all this calls sum up
>>> > and make rendering pages in Horizon much more slower than it could
>>> > be. Is it possible to provide special API calls to alleviate this?
>>> >
>>> > [1]
>>> >
>>> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
>>> >
>>> >
>>>  __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > <
>>> http://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
>>> >
>>>
>>> I think Timur is asking for a way to filter on only certain resources
>>> for quota usage/limits, like volumes in cinder or instances in nova,
>>> rather than getting back all resource usage/limits per tenant.
>>>
>>> Is that correct, Timur?
>>>
>>> While it's possible to add this, I'm not sure how much time it's
>>> actually going to save in the DB query time to get the quota information
>>> for a tenant.
>>>
>>> Anyway, it's an API change so it would require a spec for nova which
>>> means we wouldn't be getting to that until at least N since we're in
>>> spec freeze for mitaka.
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> 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:
>> 

Re: [openstack-dev] [puppet] deprecation warning everywhere issue

[Emilien Macchi]

On 12/23/2015 04:30 AM, Matt Fischer wrote:
> I've pinged you on IRC to this effect but this has broken the stable
> branches which now have unresolvable dependencies on the service whose
> name has changed.
> 
> 
> Error: Could not find resource 'Keystone_endpoint[RegionOne/glance]' for
> relationship on 'Service[glance-api]' on node
> openstack-puppet-test.openstacklocal
> Error: Could not find resource 'Keystone_endpoint[RegionOne/glance]' for
> relationship on 'Service[glance-api]' on node
> openstack-puppet-test.openstacklocal
> 
> This break is specifically in glance, here:
> 
> manifests/keystone/auth.pp
> 
>   if $configure_endpoint {
> Keystone_endpoint["${region}/${real_service_name}"]  ~> Service <|
> name == 'glance-api' |>
> Keystone_endpoint["${region}/${real_service_name}"] -> Glance_image<||>
>   }
> 
> I have not checked the other modules. I will be around for reviews on
> this if you ping me via email.

Yes I know, it's because the backport in stable/liberty for the
puppet-glance patch did not merge yet...

Please review https://review.openstack.org/#/c/260695/
And all should be back again.

FYI, master is fixed (except trove, having packaging issue in RDO,
working on it at this time) and stable/liberty almost fixed when the
puppet-glance patch is merged (and I'll backport the pupper-trove patch
too).

> 
> 
> On Tue, Dec 22, 2015 at 1:42 PM, Matt Fischer  > wrote:
> 
> Thanks Emilien,
> 
> This is what I was mentioning to you on IRC last week as a must fix
> for Mitaka. I'd like to also backport this to Liberty once it lands.
> 
> On Mon, Dec 21, 2015 at 10:48 AM, Emilien Macchi  > wrote:
> 
> Hello,
> 
> I just reported [1] which affects puppet-keystone but also *all*
> modules.
> Since [2], you now have a lot of warnings about the new way to
> declare
> keystone_endpoint resource.
> 
> This is not really acceptable and provides a poor end-user
> experience to
> have (by default) a lot of warnings.
> 
> The patch that will fix it in puppet-keystone is [3] (please
> review it).
> To fix all other modules, we need to update unit tests and sometimes
> keystone/auth.pp in the module. It will requires a Depends-On the
> puppet-keystone patch, which means puppet-keystone patch will fail
> integration tests (circular dependency). Ex with [4] (puppet-glance)
> 
> So here is the plan:
> * let's review [3] but do not merge it.
> * let's review [4] and other that will follow (on same Gerrit
> topic).
> * Once all patches have been submitted, I'll send a patch to
> puppet-openstack-integration with Depends-On of all other
> patches and
> see Integration testing, so we don't break our CI.
> 
> You can follow all this work on the "endpoint/warnings" Gerrit
> topic [5].
> 
> Any other suggestion is welcome,
> Please review,
> 
> [1] https://bugs.launchpad.net/puppet-keystone/+bug/1528308
> [2]
> 
> http://git.openstack.org/cgit/openstack/puppet-keystone/commit/?id=0a4e06abb0f5b3f324464ff5219d2885816311ce
> [3] https://review.openstack.org/#/c/259996/
> [4] https://review.openstack.org/#/c/260044/
> [5] https://review.openstack.org/#/q/topic:endpoint/warnings
> --
> 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
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 22 December 2015 at 16:56, Clint Byrum  wrote:

> Excerpts from Dougal Matthews's message of 2015-12-22 07:36:02 -0800:
> > Hi all,
> >
> > This topic came up in the 2015-12-15 meeting[1], and again briefly today.
> > After working with the code that came out of the deployment library
> spec[2]
> > I
> > had some concerns with how we are storing the templates.
> >
> > Simply put, when we are dealing with 100+ files from
> tripleo-heat-templates
> > how can we ensure consistency in Swift without any atomicity or
> > transactions.
> > I think this is best explained with a couple of examples.
> >
> >  - When we create a new deployment plan (upload all the templates to
> swift)
> >how do we handle the case where there is an error? For example, if we
> are
> >uploading 10 files - what do we do if the 5th one fails for some
> reason?
> >There is a patch to do a manual rollback[3], but I have concerns about
> >doing this in Python. If Swift is completely inaccessible for a short
> >period the rollback wont work either.
> >
>
> You could create a unique swift container, upload things to that, and
> then update a pointer in a well-known location to point at that container
> for the new plan only after you've verified it is available. This is a
> primitive form of Read-copy-update.
>
> >  - When deploying to Heat, we need to download all the YAML files from
> > Swift.
> >This can take a couple of seconds. What happens if somebody starts to
> >upload a new version of the plan in the middle? We could end up
> trying to
> >deploy half old and half new files. We wouldn't have a consistent
> view of
> >the database.
> >
>
> Perhaps you should land a change in Heat to allow templates to be directly
> downloaded by the engine from swift without needing to be uploaded. In
> the past allowing URLs to be downloaded unfettered was disabled because
> we don't want Heat to be a DoS engine, but swift would be in-cloud and
> could be restricted to the stack owner.
>
> > We had a few suggestions in the meeting:
> >
> >  - Add a locking mechanism. I would be concerned about deadlocks or
> having
> > to
> >lock for the full duration of a deploy.
>
> Deadlocks only happen when competing interests lock _two_ things in
> different order. Have one thing to lock, and you don't have to worry
> about this.
>

Good point. Sorry, I am getting my terminology confused. I can't think what
the
word is, but I was worried about stale locks getting lost and locking
everything up.
Where would we store the lock? On the machine running the API maybe?


>  - Store the files in a tarball (so we only deal with one file). I think
> we
> >could still hit issues with multiple operations unless we guarantee
> that
> >only one instance of the API is ever running.
> >
> > I think these could potentially be made to work, but at this point are we
> > using the best tool for the job?
> >
> > For alternatives, I see a can think of a couple of options:
> >
> > - Use a database, like we did for Tuskar and most OpenStack API's do.
>
> It's worth noting that many OpenStack API's/daemons are using the
> database + MQ to provide consistency in a distributed fashion, and many
> have identified that this doesn't scale particularly well, and looking
> at tooz to help bring in DLM's. In fact, a spec recently landed around
> this:
>
>
> http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html
>
> So if you are only using the DB for consistency, you might want to just
> use tooz+swift.
>

Interesting! I hadn't come across this and I'll look into it. Thanks.



>
> > - Invest time in building something on Swift.
> > - Glance was transitioning to be a Artifact store. I don't know the
> status
> > of
> >   this or if it would meet out needs.
>
> I'd say the artifact store is more about exposing options to users, and
> less about providing primitives for an API.
>
> __
> 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] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 22 December 2015 at 18:50, Julien Danjou  wrote:

> On Tue, Dec 22 2015, Dougal Matthews wrote:
>
> >  - Store the files in a tarball (so we only deal with one file). I think
> we
> >could still hit issues with multiple operations unless we guarantee
> that
> >only one instance of the API is ever running.
>
> That shouldn't be a problem since the store/update is atomic. So if you
> upload a new version while downloading it for deployments, you'll just
> get the old version this time.
> In the end, you won't have a mixed of both version, which is likely what
> you want.
>

Good to know, thanks. I guess the remaining issue would be with the work
Tomas Sedovic mentioned. It sounds like Swift might not work well there.


>
> So that sounds like a good and simple solution from what I understand.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
__
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] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 22 December 2015 at 17:59, Ben Nemec  wrote:

> Can we just do git like I've been suggesting all along? ;-)
>
> More serious discussion inline. :-)
>
> On 12/22/2015 09:36 AM, Dougal Matthews wrote:
> > Hi all,
> >
> > This topic came up in the 2015-12-15 meeting[1], and again briefly today.
> > After working with the code that came out of the deployment library
> > spec[2] I
> > had some concerns with how we are storing the templates.
> >
> > Simply put, when we are dealing with 100+ files from
> tripleo-heat-templates
> > how can we ensure consistency in Swift without any atomicity or
> > transactions.
> > I think this is best explained with a couple of examples.
> >
> >  - When we create a new deployment plan (upload all the templates to
> swift)
> >how do we handle the case where there is an error? For example, if we
> are
> >uploading 10 files - what do we do if the 5th one fails for some
> reason?
> >There is a patch to do a manual rollback[3], but I have concerns about
> >doing this in Python. If Swift is completely inaccessible for a short
> >period the rollback wont work either.
> >
> >  - When deploying to Heat, we need to download all the YAML files from
> > Swift.
> >This can take a couple of seconds. What happens if somebody starts to
> >upload a new version of the plan in the middle? We could end up
> trying to
> >deploy half old and half new files. We wouldn't have a consistent
> view of
> >the database.
> >
> > We had a few suggestions in the meeting:
> >
> >  - Add a locking mechanism. I would be concerned about deadlocks or
> > having to
> >lock for the full duration of a deploy.
>
> There should be no need to lock the plan for the entire deploy.  It's
> not like we're re-reading the templates at the end of the deploy today.
>  It's a one-shot read and then the plan could be unlocked, at least as
> far as I know.
>

Good point. That would be holding the lock for longer than we need.


The only option where we wouldn't need locking at all is the
> read-copy-update model Clint mentions, which might be a valid option as
> well.  Whatever we do, there are going to be concurrency issues though.
>  For example, what happens if two users try to make updates to the plan
> at the same time?  If you don't either merge the changes or disallow one
> of them completely then one user's changes might be lost.
>
> TBH, this is further convincing me that we should just make this git
> backed and let git handle the merging and conflict resolution (never
> mind the fact that it gets us a well-understood version control system
> for "free").  For updates that don't conflict with other changes, git
> can merge them automatically, but for merge conflicts you just return a
> rebase error to the user and make them resolve it.  I have a feeling
> this is the behavior we'll converge on eventually anyway, and rather
> than reimplement git, let's just use the real thing.
>

I'd be curious to hear more how you would go about doing this with git. I've
never automated git to this level, so I am concerned about what issues we
might hit.

Do you happen to know of any good sources that I can find out more?


/2 cents
>
> >  - Store the files in a tarball (so we only deal with one file). I think
> we
> >could still hit issues with multiple operations unless we guarantee
> that
> >only one instance of the API is ever running.
> >
> > I think these could potentially be made to work, but at this point are we
> > using the best tool for the job?
> >
> > For alternatives, I see a can think of a couple of options:
> >
> > - Use a database, like we did for Tuskar and most OpenStack API's do.
>
> I kind of like this, in particular because it would allow us to handle
> migrations between versions the same way as other OpenStack services.
>

Yeah, I feel like this is the "safe" option. It's a well trodden and tested
path.


> I'm not entirely sure how it maps to our template configuration method
> though.  Storing a bunch of template blobs in the database feels a
> little square peg, round hole to me, and might undo a lot of the
> benefits of using the database in the first place.
>

I don't follow this point. In the way we access Swift, everything is
essentially
a blob of text also.


> Now, on the other hand, having a database to store basic data like
> metadata on plans and such might be a useful thing regardless of where
> we store the templates themselves.  We could also use it for locking
> just fine IMHO - TripleO isn't a tool targeted to have cloud-scale
> number of users.  It's a deployer tool with a relatively limited number
> of users per installation, so the scaling of a locking mechanism isn't a
> problem I necessarily think we need to solve.  We have way bigger
> scaling issues than that to tackle before I think we would hit the limit
> of a database-locking scheme.
>
> > - Invest time in building something on Swift.
> > - Glance was 

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Julien Danjou]

On Wed, Dec 23 2015, Dougal Matthews wrote:

> Good to know, thanks. I guess the remaining issue would be with the work
> Tomas Sedovic mentioned. It sounds like Swift might not work well there.

Right, reply below.

On Tue, Dec 22 2015, Tomas Sedovic wrote:

> At minimum, we'd have to store the validation results somewhere and be able to
> query them per stage, validation and (optionally) plan. That could be done in
> Swift or filesystem/git as well, but we'd have to write code to handle 
> indexing
> and querying and at that point using a DB seems easier.

Yes, as long as you don't need proper indexing, you can go with Swift
(or any object storage), otherwise, it's starting to be blurry. That's
why we have a composite solution in Gnocchi: we store data file (time
series) in Swift containers (or Ceph pools), and for many operations, we
don't rely on our SQL index, as listing a container is enough. This
makes many operation largely scalable and distributive.

Though, as soon as you need something like "the list of time series of
this user", you need an index. And that's where (and only where) we
start poking our SQL index.

Now, if your data files are pretty small and can easily fit in a RDBMS,
it's worth questioning the object storage usage at all indeed.

My 2ç,

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP 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

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Dougal Matthews]

On 22 December 2015 at 19:29, Dan Prince  wrote:

> On Tue, 2015-12-22 at 15:36 +, Dougal Matthews wrote:
> > Hi all,
> >
> > This topic came up in the 2015-12-15 meeting[1], and again briefly
> > today.
> > After working with the code that came out of the deployment library
> > spec[2] I
> > had some concerns with how we are storing the templates.
> >
> > Simply put, when we are dealing with 100+ files from tripleo-heat-
> > templates
> > how can we ensure consistency in Swift without any atomicity or
> > transactions.
> > I think this is best explained with a couple of examples.
> >
> >  - When we create a new deployment plan (upload all the templates to
> > swift)
> >how do we handle the case where there is an error? For example, if
> > we are
> >uploading 10 files - what do we do if the 5th one fails for some
> > reason?
> >There is a patch to do a manual rollback[3], but I have concerns
> > about
> >doing this in Python. If Swift is completely inaccessible for a
> > short
> >period the rollback wont work either.
> >
> >  - When deploying to Heat, we need to download all the YAML files
> > from Swift.
> >This can take a couple of seconds. What happens if somebody starts
> > to
> >upload a new version of the plan in the middle? We could end up
> > trying to
> >deploy half old and half new files. We wouldn't have a consistent
> > view of
> >the database.
> >
> > We had a few suggestions in the meeting:
> >
> >  - Add a locking mechanism. I would be concerned about deadlocks or
> > having to
> >lock for the full duration of a deploy.
> >  - Store the files in a tarball (so we only deal with one file). I
> > think we
> >could still hit issues with multiple operations unless we
> > guarantee that
> >only one instance of the API is ever running.
>
> I may be partial to trying out the above solutions because I was in the
> meeting. Before we write these off shouldn't we prototype them out
> first?
>

Sure, I would be interested in seeing prototypes. I think the hardest
problem will be validating the prototypes and making sure they are flexible
enough going forward.

At the moment all the Swift interaction is in one storage backend[1], it
might be that the best way forward is to support multiple options and then
we can see over time which works best. However, the likely outcome would
be that the default is the one that wins regardless.


Anyways, I feel like the title of this thread is a bit loaded. Swift
> may not be the best "database"... but if our goal is to use it for
> object storage while we design set of workflows to help us deploy
> things then I think it might fit in nicely.
>

That's fair, the subject was probably a bit sensationalist. I actually
intended
to change it to "store", but the difference is neither here nor there now.


Dan
>
> >
> > I think these could potentially be made to work, but at this point
> > are we
> > using the best tool for the job?
> >
> > For alternatives, I see a can think of a couple of options:
> >
> > - Use a database, like we did for Tuskar and most OpenStack API's do.
> > - Invest time in building something on Swift.
> > - Glance was transitioning to be a Artifact store. I don't know the
> > status of
> >   this or if it would meet out needs.
> >
> > Any input, ideas or suggestions would be great!
> >
> > Thanks,
> > Dougal
> >
> >
> > [1]: http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.201
> > 5-12-15-14.03.log.html#l-89
> > [2]: https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka
> > /tripleo-overcloud-deployment-library.html
> > [3]: https://review.openstack.org/#/c/257481/
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack][magnum]a problem about trust

[Steven Hardy]

On Tue, Dec 22, 2015 at 04:55:17PM +0800, 王华 wrote:
>Hi all,
>When we create a trust to a trustee with a role, the trustor must have
>this role. Here is a problem I meet in my bp [1]. I need to create a trust
>with a role, with the trust docker registry can access Swift to store
>images. But the trustor (the user who uses magnum) may not have the role.
>How can we address this problem?

FYI we had this exact same issue in Heat some time ago:

https://bugs.launchpad.net/heat/+bug/1376562

>There are two ways.
>1. Add the role to the trustor with the magnum admin user privilege. But
>when we need to delete the role, we can not know whether the role is added
>by magnum or is owned by the trustor.
>2. Let magnum trust the trustee with the role. We can assign the role to
>magnum before we start magnum. 

As you'll see from the bug report above, neither of these solutions work,
because you can't know at the point of delegation what roles may be needed
in the future when impersonating the trustor.

So, having a special role which is always delegated (as you are proposing,
and Heat used to do) doesn't work very well in environments where RBAC is
actually used.

The solution we reached in Heat is to delegate all roles, as determined by
keystone/authtoken, with the option for deployers to specify some specific
role or list of roles if they have an RBAC scheme where the expected roles
are predictable:

See https://review.openstack.org/128509 for the Heat solution.

HTH!

Steve

__
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-Infra] Gerrit Upgrade to ver 2.11, completed.

[Michał Dulko]

On 12/22/2015 10:52 PM, Carl Baldwin wrote:
> On Mon, Dec 21, 2015 at 6:21 PM, Zaro  wrote:
>> Hit '?' and it says '/' is find, give that a try.
> '/' isn't really much better.  It seems to highlight all of the
> occurrences but I can't find a way to navigate to the next/previous
> occurence with the keyboard.  I see that the scroll bar shows a small
> indication that there are many matches within the file and so I could
> scroll to them if I want to move my fingers to the trackpad to scroll.

n goes to next occurrence and N (shift+n) to a previous one. These are
same keybindings as in Vim. Actually a lot of Vim-like movements are
functional in new Gerrit and I really like that fact.

__
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] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[Michał Dulko]

On 12/22/2015 09:01 PM, Erlon Cruz wrote:
> Hmm, I see. There's this spec[1] that was discussed in the past with a
> similar proposal. There's a SPEC with some other points on the
> discussion, I think Janice forgot to mention.
>
> Erlon
>
> [1] https://review.openstack.org/#/c/176233/
> [2] https://review.openstack.org/#/c/258968/

It seems to me that these two are actually not that much related. [1]
proposes to use RPC calls to determine if a service is alive, but only
in cinder-manage commands. In [2] whole health check mechanism that is
used by scheduler is proposed to be replaced by Tooz, which isn't using RPC.

__
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