Re: [openstack-dev] [masakari] Intrusive Instance Monitoring

[Sam P]

Hi Greg,

# Thank you Jeremy..!

 I couldn't find any problem with repo side.
 As Jeremy pointed out, could you please check the `git remote show gerrit`.

BTW, could you please create a BP in [1] and link it to your spec when
you commit it.
In this way, we could track all the changes related to this task.
Please include the related bp Name in commit massage of your spec as,

Implements: bp name-of-your-bp
# Please refer to open to review spec [2] for more details.
# You may find more details on [3]

[1] https://blueprints.launchpad.net/masakari
[2] https://review.openstack.org/#/c/458023/4//COMMIT_MSG
[3] 
https://docs.openstack.org/infra/manual/developers.html#working-on-specifications-and-blueprints
--- Regards,
Sampath



On Tue, May 30, 2017 at 4:39 AM, Jeremy Stanley  wrote:
> On 2017-05-29 14:48:10 + (+), Waines, Greg wrote:
>> Was just trying to submit my spec for Intrusive Instance
>> Monitoring for review.
>>
>> And I get the following warning after committing when I do the
>> ‘git review’
>>
>> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review
>> You are about to submit multiple commits. This is expected if you are
>> submitting a commit that is dependent on one or more in-review
>> commits. Otherwise you should consider squashing your changes into one
>> commit before submitting.
>>
>> The outstanding commits are:
>>
>> f09deee (HEAD -> myBranch) Initial draft specification of Intrusive Instance 
>> Monitoring.
>> 21aeb96 (origin/master, origin/HEAD, master) Prepare specs repository for 
>> Pike
>> 83d1a0a Implement reserved_host, auto_priority and rh_priority recovery 
>> methods
>> 4e746cb Add periodic task to clean up workflow failure
>> 2c10be4 Add spec repo structure
>> a82016f Added .gitreview
>>
>> Do you really want to submit the above commits?
>> Type 'yes' to confirm, other to cancel: no
>> Aborting.
>> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$
>>
>> Seems like my clone picked up someone else’s open commit ?
>>
>> Any help would be appreciated,
>> The full log of my git session is below,
> [...]
>
> The output doesn't show any open changes, but rather seems to
> indicate that the parent is the commit at the tip of origin/master.
> This condition shouldn't normally happen unless Gerrit doesn't
> actually know about any of those commits for some reason.
>
> One thing, I notice your `git review -s` output in your log was
> empty. Make sure the output of `git remote show gerrit` looks
> something like this (obviously with your username in place of mine):
>
> * remote gerrit
>   Fetch URL: 
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
>   Push  URL: 
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
>   HEAD branch: master
>   Remote branch:
> master tracked
>   Local ref configured for 'git push':
> master pushes to master (up to date)
>
> Using git-review 1.25.0 I attempted to replicate the issue like
> this, but everything worked normally:
>
> fungi@dhole:~/work/openstack/openstack$ git clone 
> https://github.com/openstack/masakari-specs.git
> Cloning into 'masakari-specs'...
> remote: Counting objects: 61, done.
> remote: Total 61 (delta 0), reused 0 (delta 0), pack-reused 61
> Unpacking objects: 100% (61/61), done.
> fungi@dhole:~/work/openstack/openstack$ cd masakari-specs/
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git log
> commit 21aeb965acea0b3ebe8448715bb88df4409dd402
> Author: Abhishek Kekane 
> Date:   Wed Apr 19 16:00:53 2017 +0530
>
> Prepare specs repository for Pike
>
> Add directories, index file, and template symlinks for Pike specs.
>
> Change-Id: I7dce74430e4569a5978f8f4b953db3b20125c53e
>
> commit 83d1a0aae17e4e8110ac64c7975a8520592712f9
> Author: Abhishek Kekane 
> Date:   Fri Jan 20 12:00:12 2017 +0530
>
> Implement reserved_host, auto_priority and rh_priority recovery 
> methods
>
> Implements: bp implement-recovery-methods
> Change-Id: I83ce204d8f25b240fa6ce723dc15192ae9b4e191
>
> commit 4e746cb5a39df5aa833ab32ce7ba961637753a15
> Author: Abhishek Kekane 
> Date:   Fri Jan 20 11:38:09 2017 +0530
>
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git review -s
> Creating a git remote called 'gerrit' that maps to:
> 
> ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git checkout -b 
> myBranch
> Switched to a new branch 'myBranch'
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ cp 
> doc/source/specs/pike/implemented/pike-template.rst 
> doc/source/specs/pike/implemented/vmHeartbeat.masa
> kari.specfile.rst
> fungi@dhole:~/work/openstack/openstack/masakari-specs$ git add 
> 

Re: [openstack-dev] [TripleO] overcloud_containers.yaml: container versioning, tags and use cases ?

[Steve Baker]

On Sat, May 27, 2017 at 7:07 AM, David Moreau Simard  wrote:

> Hi,
>
> Today we discussed a challenge around image tags that mostly boils
> down to limitations in how overcloud_containers.yaml is constructed
> and used.
>
> TL;DR, we need a smart and easy way to work with the
> overcloud_containers.yaml file (especially tags).
>
> Let's highlight a few use cases that we need to work through:
>
> #1. Building containers
>   For building containers, all we really care is the name of the
> images we need to build.
>   Today, we install a trunk repository and then install
> tripleo-common-containers from that trunk repository.
>   We then mostly grep/sed/awk our way from overcloud_containers.yaml
> to a clean list of images to build and then build those.
>   Relatively okay with this but prone to things breaking -- a clean
> way to get just the list of images out of there would be nice.
>
>
The command "openstack overcloud container image build" also has some
string matching logic, but then invokes kolla-build directly.

Can I suggest that we add a --list-images option to this command so that it
just returns a list of images for other image building tools to consume?


> #2. Testing and promoting containers
>   This comes right after use case #1 where we build containers in the
> pipeline.
>   For those familiar with the CI pipeline to do promotions [1], this
> would look a bit like this [2].
>
>   In practice, this works basically the same way as we build, test and
> promote tripleo-quickstart images.
>   We pick a particular trunk repository hash and build containers for
> that hash. These are then pushed with both the tags ":latest" and
> ":".
>   We're then supposed to test those containers in the pipeline but to
> do that, we need to be pulling from :, not :latest...
> although they are in theory equivalent at that given time, this might
> not always be true.
>   So the testing job(s) need a way to easily customize/pull from that
> particular hash instead of the hardcoded latest we have right now.
>
>
I would like to see another "openstack overcloud container image ..."
command which is pointed at an image registry and a
canonical overcloud_containers.yaml file, then generates
another overcloud_containers.yaml (and heat environment file) which
contains the proper latest  tags. This tool could work too for
stable version-style tags.

How about "openstack overcloud container image discover"?

This would be easier to implement if the canonical
overcloud_containers.yaml file was a template rather than a file with
hard-coded namespace and tags.


> #3. Upstream gate jobs
>   Ideally, gate jobs should never use ":latest". This is in trunk/dlrn
> terms the equivalent of "/current/" or "/consistent/".
>   They'd use something like ":latest-passed-ci" which would be the
> proper equivalent of "/current-passed-ci/" or "/current-tripleo/".
>
>
There is nothing special about the word latest. Can we give these images
the same tag as the name of the package repo they came from? so
:current-passed-ci :current-tripleo?


>   This brings an interesting challenge around how we currently add new
> images to overcloud_containers.yaml (example [3]).
>   It is expected that, when you add the image, the image is already
> present on the registry because otherwise the container jobs will fail
> since this new image cannot be pulled (example [4]).
>   My understanding currently is that humans may build and push images
> to the registry ahead of time so that this works.
>   We can keep a similar approach if that's what we really want with
> the new private registry, the job that builds container is made
> generic exactly to be able to build just a specific set of image(s) if
> we want.
>   Here's the catch, though: this new container image will have the
> ":latest" tag, it will not have ":latest-passed-ci" because it hasn't
> passed CI yet, it's being added just now.
>   So how do we address this ?
>
>
Here is an idea, the "discover" command mentioned above could filter images
based on their presence in the registry with the required tags, so the
resulting generated overcloud_containers.yaml would have less entries if
there is no image with the requested tag.


>   Note:
>   We've already discussed that some containers need to pick up the
> latest and the greatest from the "/current/" repository, either
> because they are "direct" tripleo packages or if "Depends-On" is used.
>   So far, the solution we seem to be going towards is to pick up the
> containers from ":latest-passed-ci" and then more or less add a 'yum
> update' layer to the images needing an update.
>   This is the option that is in the best interest of time, we'd
> otherwise be spending too much time building containers in jobs that
> are already taking way too long to run.
>

That is a shame, I have no suggestions to avoid this though.


> #4. Test days
>   When doing test days, we know to point testers to
> /current-passed-ci/ as well as tested 

Re: [openstack-dev] [masakari] Intrusive Instance Monitoring

[Jeremy Stanley]

On 2017-05-29 14:48:10 + (+), Waines, Greg wrote:
> Was just trying to submit my spec for Intrusive Instance
> Monitoring for review.
> 
> And I get the following warning after committing when I do the
> ‘git review’
> 
> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review
> You are about to submit multiple commits. This is expected if you are
> submitting a commit that is dependent on one or more in-review
> commits. Otherwise you should consider squashing your changes into one
> commit before submitting.
> 
> The outstanding commits are:
> 
> f09deee (HEAD -> myBranch) Initial draft specification of Intrusive Instance 
> Monitoring.
> 21aeb96 (origin/master, origin/HEAD, master) Prepare specs repository for Pike
> 83d1a0a Implement reserved_host, auto_priority and rh_priority recovery 
> methods
> 4e746cb Add periodic task to clean up workflow failure
> 2c10be4 Add spec repo structure
> a82016f Added .gitreview
> 
> Do you really want to submit the above commits?
> Type 'yes' to confirm, other to cancel: no
> Aborting.
> gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$
> 
> Seems like my clone picked up someone else’s open commit ?
> 
> Any help would be appreciated,
> The full log of my git session is below,
[...]

The output doesn't show any open changes, but rather seems to
indicate that the parent is the commit at the tip of origin/master.
This condition shouldn't normally happen unless Gerrit doesn't
actually know about any of those commits for some reason.

One thing, I notice your `git review -s` output in your log was
empty. Make sure the output of `git remote show gerrit` looks
something like this (obviously with your username in place of mine):

* remote gerrit
  Fetch URL: 
ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
  Push  URL: 
ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
  HEAD branch: master
  Remote branch:
master tracked
  Local ref configured for 'git push':
master pushes to master (up to date)

Using git-review 1.25.0 I attempted to replicate the issue like
this, but everything worked normally:

fungi@dhole:~/work/openstack/openstack$ git clone 
https://github.com/openstack/masakari-specs.git
Cloning into 'masakari-specs'...
remote: Counting objects: 61, done.
remote: Total 61 (delta 0), reused 0 (delta 0), pack-reused 61
Unpacking objects: 100% (61/61), done.
fungi@dhole:~/work/openstack/openstack$ cd masakari-specs/
fungi@dhole:~/work/openstack/openstack/masakari-specs$ git log
commit 21aeb965acea0b3ebe8448715bb88df4409dd402
Author: Abhishek Kekane 
Date:   Wed Apr 19 16:00:53 2017 +0530

Prepare specs repository for Pike

Add directories, index file, and template symlinks for Pike specs.

Change-Id: I7dce74430e4569a5978f8f4b953db3b20125c53e

commit 83d1a0aae17e4e8110ac64c7975a8520592712f9
Author: Abhishek Kekane 
Date:   Fri Jan 20 12:00:12 2017 +0530

Implement reserved_host, auto_priority and rh_priority recovery methods

Implements: bp implement-recovery-methods
Change-Id: I83ce204d8f25b240fa6ce723dc15192ae9b4e191

commit 4e746cb5a39df5aa833ab32ce7ba961637753a15
Author: Abhishek Kekane 
Date:   Fri Jan 20 11:38:09 2017 +0530

fungi@dhole:~/work/openstack/openstack/masakari-specs$ git review -s
Creating a git remote called 'gerrit' that maps to:
ssh://fu...@review.openstack.org:29418/openstack/masakari-specs.git
fungi@dhole:~/work/openstack/openstack/masakari-specs$ git checkout -b 
myBranch
Switched to a new branch 'myBranch'
fungi@dhole:~/work/openstack/openstack/masakari-specs$ cp 
doc/source/specs/pike/implemented/pike-template.rst 
doc/source/specs/pike/implemented/vmHeartbeat.masa
kari.specfile.rst
fungi@dhole:~/work/openstack/openstack/masakari-specs$ git add 
specs/pike/implemented/vmHeartbeat.masakari.specfile.rst
fungi@dhole:~/work/openstack/openstack/masakari-specs$ git commit
[myBranch 9e5c70e] Test commit
 1 file changed, 389 insertions(+)
 create mode 100644 specs/pike/implemented/vmHeartbeat.masakari.specfile.rst
fungi@dhole:~/work/openstack/openstack/masakari-specs$ git review
remote: Processing changes: new: 1, refs: 1, done
remote:
remote: New Changes:
remote:   https://review.openstack.org/468941 Testing, do not review
remote:
To ssh://review.openstack.org:29418/openstack/masakari-specs.git
 * [new branch]  HEAD -> refs/publish/master/myBranch

-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [infra] Removal of git-review from DIB images

[Jeremy Stanley]

On 2017-05-29 08:49:30 -0400 (-0400), Paul Belanger wrote:
> Does your project use git-review on our zuul worker nodes? If so,
> this post is for you.
[...]
> I have proposed the removal of git-review[1] from our
> images.

After subsequent discussion in IRC (spotty due to it being a
national holiday for a few of us), this was merged. Since git-review
doesn't work without credentials for a corresponding Gerrit account
and we don't currently entrust our single-use nodes (the only ones
using these images) with such credentials, the removal should have
no impact.

Of course, if our logic here is flawed and you do have a job somehow
using git-review on single-use nodes then by all means make sure
your job installs git-review directly.
-- 
Jeremy Stanley


signature.asc
Description: 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] Security bug in diskimage-builder

[Jeremy Stanley]

On 2017-05-29 15:43:43 +0200 (+0200), Emilien Macchi wrote:
> On Wed, May 24, 2017 at 7:45 PM, Ben Nemec  wrote:
[...]
> > Emilien, I think we should create a tripleo-coresec group in
> > launchpad that can be used for this. We have had
> > tripleo-affecting security bugs in the past and I imagine we
> > will again. I'm happy to help out with that, although I will
> > admit my launchpad-fu is kind of weak so I don't know off the
> > top of my head how to do it.
> 
> That or re-use an existing Launchpad group used by OpenStack VMT?

The OpenStack VMT doesn't triage bugs for deliverables aside from
those tagged with vulnerability:managed in governance. For those we
recommend private security bugs only be automatically shared with
the openstack-vuln-mgmt team in LP, and then we manually subscribe
something-coresec to the report once we're sure it was reported
against the correct project. For deliverables without VMT oversight,
it makes sense to have private security bugs automatically shared
with those something-coresec teams directly.

https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html

-- 
Jeremy Stanley


signature.asc
Description: 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] [kolla][osprofiler][keystone][neutron][nova] osprofiler in paste deploy files

[Matthieu Simonin]

- Mail original -
> De: "Eduardo Gonzalez" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Envoyé: Lundi 29 Mai 2017 11:53:53
> Objet: Re: [openstack-dev] [kolla][osprofiler][keystone][neutron][nova] 
> osprofiler in paste deploy files
> 
> Hi Matt,
> 
> A), As far I can see most services with Osprofile implemented have it
> enabled by default at paste-ini files except Neutron and maybe a couple
> more.
> 
> B), kolla's custom keystone-paste-ini file will probably be "removed" for
> Pike release, using keystone defaults with osprofile enabled. We will add
> other method to customize paste-ini, ofc.

Is there any reference on a (future) method to customize paste-ini files ?
This would be a really helpful feature (and not only for OSProfiler).

> 
> C), For now in kolla, neutron paste-ini cannot be customized by regular
> methods, a quick but no good solution would be exec into container, modify
> the file and restart container, or modify kolla-ansible playbooks to allow
> copying your custom api-paste.ini.
> 
> Agree that option A is the best method.
> 
> FYI, at this moment there is a change under review to implement osprofile
> in kolla-ansible. [0]

Thanks for pointing me this. It seems a complementary feature to fully enable 
OSProfiler in Kolla. In my opinion, making sure the various api-paste files 
enable 
OSProfiler is something that goes first.

Best,

Matt

> 
> [0] https://review.openstack.org/#/c/455628/
> 
> Regards, Eduardo
> 
> __
> OpenStack Development Mailing 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] [os-upstream-institute] Today's meeting is CANCELED

[Ildiko Vancsa]

Hi Team,

Due to the holiday today in the US today’s meeting is canceled.

See you next Monday (June 5th), 2000 UTC on #openstack-meeting-3.

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

[openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

[Saverio Proto]

Hello,

I have a question about the l2gw. I did a deployment, I described the
steps here:
https://review.openstack.org/#/c/453209/

The unicast traffic works fine, but I dont understand what is the idea
behind the handling of the broadcast traffic.

Looking at openvswitch:

I obtain the uuid with `vtep-ctl list-ls`

vtep-ctl list-remote-macs 

In this output I get an entry for each VM that has an interface in the
L2 network I am bridging:


# vtep-ctl list-remote-macs 
ucast-mac-remote
  fa:16:3e:c2:7b:da -> vxlan_over_ipv4/10.1.1.167

mcast-mac-remote
-

The ucast-mac-remote entry is created by Openstack when I start a VM.
(Also it is never removed when I delete the instance, is this a bug ? )
Note that 10.1.1.167 is the IP address of the hypervisor where the VM is
running.

But mcast-mac-remote is empty. So this means that ARP learning for
example works only in 1 way. The VM in openstack does not receive any
broadcast traffic, unless I do manually:

vtep-ctl add-mcast-remote ee87db33-1b3a-42e9-bc09-02747f8a0ad5
unknown-dst  10.1.1.167

This creates an entry in the table mcast-mac-remote and everything works
correctly.


Now I read here http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
about sending add-mcast-remote to the network nodes and then doing some
magic I dont really understand. But I am confused because in my setup
the tenant does not have a L3 router, so there is not a qrouter
namespace for this network, I was planning to keep the network node out
of the game.

Is anyone running this in production and can shed some light ?

thanks

Saverio











-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] [masakari] Intrusive Instance Monitoring

[Waines, Greg]

Hey Sam,
Was just trying to submit my spec for Intrusive Instance Monitoring for review.

And I get the following warning after committing when I do the ‘git review’
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review
You are about to submit multiple commits. This is expected if you are
submitting a commit that is dependent on one or more in-review
commits. Otherwise you should consider squashing your changes into one
commit before submitting.

The outstanding commits are:

f09deee (HEAD -> myBranch) Initial draft specification of Intrusive Instance 
Monitoring.
21aeb96 (origin/master, origin/HEAD, master) Prepare specs repository for Pike
83d1a0a Implement reserved_host, auto_priority and rh_priority recovery methods
4e746cb Add periodic task to clean up workflow failure
2c10be4 Add spec repo structure
a82016f Added .gitreview

Do you really want to submit the above commits?
Type 'yes' to confirm, other to cancel: no
Aborting.
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$

Seems like my clone picked up someone else’s open commit ?

Any help would be appreciated,
The full log of my git session is below,
thanks
Greg.




gwaines@gwaines-VirtualBox:~/openstack$ git clone 
https://github.com/openstack/masakari-specs.git
Cloning into 'masakari-specs'...
remote: Counting objects: 61, done.
remote: Total 61 (delta 0), reused 0 (delta 0), pack-reused 61
Unpacking objects: 100% (61/61), done.
Checking connectivity... done.
gwaines@gwaines-VirtualBox:~/openstack$ cd masakari-specs/
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review -s
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git checkout -b myBranch
Switched to a new branch 'myBranch'
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git status
On branch myBranch
nothing to commit, working directory clean
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ cd doc/source/specs/pike/
approved/implemented/
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ cd 
doc/source/specs/pike/implemented
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 ls
pike-template.rst
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 cp /tmp/vmHeartbeat.masakari.specfile.rst .
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 ls -l
total 12
lrwxrwxrwx 1 gwaines gwaines23 May 29 10:37 pike-template.rst -> 
../../pike-template.rst
-rw-rw-r-- 1 gwaines gwaines 5 May 29 10:38 
vmHeartbeat.masakari.specfile.rst
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 git status
On branch myBranch
Untracked files:
  (use "git add ..." to include in what will be committed)

  vmHeartbeat.masakari.specfile.rst

nothing added to commit but untracked files present (use "git add" to track)
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 git add vmHeartbeat.masakari.specfile.rst
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 git status
On branch myBranch
Changes to be committed:
  (use "git reset HEAD ..." to unstage)

  new file:   vmHeartbeat.masakari.specfile.rst

gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source/specs/pike/implemented$
 cd ../../../
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs/doc/source$ cd ../../
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ cd
gwaines@gwaines-VirtualBox:~$ cd openstack/masakari-specs/
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ ls
doc  README.rstsetup.cfg  specs test-requirements.txt
LICENSE  requirements.txt  setup.py   template.rst  tox.ini
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ pwd
/home/gwaines/openstack/masakari-specs
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git status
On branch myBranch
Changes to be committed:
  (use "git reset HEAD ..." to unstage)

  new file:   specs/pike/implemented/vmHeartbeat.masakari.specfile.rst

gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git commit -s
[myBranch f09deee] Initial draft specification of Intrusive Instance Monitoring.
1 file changed, 264 insertions(+)
create mode 100644 specs/pike/implemented/vmHeartbeat.masakari.specfile.rst
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git status
On branch myBranch
nothing to commit, working directory clean
gwaines@gwaines-VirtualBox:~/openstack/masakari-specs$ git review
You are about to submit multiple commits. This is expected if you are
submitting a commit that is dependent on one or more in-review
commits. Otherwise you should consider squashing your changes into one
commit before submitting.

The outstanding commits are:

f09deee (HEAD -> myBranch) 

Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

[Mikhail Fedosin]

Thank you very much for your trust! I will try not to let you down, and be
with the project in these difficult times.

Despite the fact that most of the time I'm involved in the Glare project, I
agree that they have much in common. And at least they both share
glance_store library. For this reason, I'm thinking of implementing the
multi-storage support, where operators can create various settings for
different stores. For instance, having multiple connected ceph data stores.
The rest of the time I plan to review the code, write tests and fix minor
bugs.

I'm glad to be a part of the community!

Best,
Mike

On Fri, May 26, 2017 at 7:28 AM, feilong  wrote:

> Welcome back, Mike.
>
> On 26/05/17 16:21, Kekane, Abhishek wrote:
>
> +1, agree with Nikhil.
>
>
>
> Abhishek
>
>
>
> *From:* Nikhil Komawar [mailto:nik.koma...@gmail.com
> ]
> *Sent:* Friday, May 26, 2017 6:04 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [glance] nominating Mike Fedosin for
> glance core
>
>
>
> This is great news. Always +2 for Mike, he's been great (dev, glancer,
> stacker ..) all the years.  Let's not wait so long for reinstatement if
> folks are on-board, as having another core will only help.
>
>
>
> On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita <
> rosmaita.foss...@gmail.com> wrote:
>
> As you've no doubt read elsewhere on the ML, we've lost several glance
> cores recently due to employment changes.  Luckily, Mike Fedosin
> informed me at today's Glance weekly meeting that he will have time
> for the next few months to devote some time to Glance reviewing.
>
> For those who don't know Mike (mfedosin on IRC), he was a Glance core
> for several years.  He provided a lot of notes that were used to write
> the Glance architecture documentation that is so helpful to new
> contributors, so he's extremely knowledgeable about the design
> patterns used in Glance.
>
> Most recently, Mike's been working on the Glare project, which has a
> lot in common with Glance.  While Mike says he can't commit much time
> to Glance development, he has proposed porting some of the Glare tests
> over to Glance, which will certainly help with our code coverage, and
> would be a helpful addition to Glance.
>
> (Mike agreed at today's Glance meeting not to propose re-integrating
> Glare into the Glance project until the Queens PTG (if at all), so I'm
> not worried about that being a distraction during the Pike cycle when
> we are so short-handed.)
>
> I'd like to reinstate Mike as a Glance core contributor at the next
> Glance weekly meeting.  Please reply to this message with any comments
> or concerns before 23:59 UTC on Wednesday 31 May 2017.
>
> cheers,
> brian
>
> __
> OpenStack Development Mailing 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,
>
> Nikhil
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
>
> __
> 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
>
>
> --
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
>
> __
> OpenStack Development Mailing 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] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Loo, Ruby]

Hi Zhenguo (and others),

is there a description/email thread/documentation about how mogan and nova 
co-exists in the same cloud? In particular, will it be possible for mogan and 
nova (with ironic driver) to run? Is this something that we will recommend or 
not recommend or not mention? Because I don't see how the end user will know to 
issue a mogan command to get a baremetal server, vs a nova-boot command to get 
a baremetal server. And/or does anyone envison that horizon will hide all that 
from the user somehow?

--ruby

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

Date: Thursday, May 25, 2017 at 10:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 
'baremetal'?



As I understand, baremetal instance in nova is a 'specical virtual machine'(raw 
performance). Users claim the instance by specifying a flavor with 'vcpus', 
'memory', "root_gb" instead of real hardware specs like (cpu model/cores, hard 
drives type/amount, nics type/amount), then he get an instance with properties 
like 'vm_state' and other 'virtual' stuff. As baremetal in nova use the same 
model and same set of API that designed for vms, so even for end users, it's 
not that easy to know which instance is a baremetal server, so maybe it's good 
to call that baremetal server a special vm instance.

So, yes the end user actually know that there is a difference between getting a 
bremetal instance via mogan or via nova :)
__
OpenStack Development Mailing 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] Security bug in diskimage-builder

[Emilien Macchi]

On Wed, May 24, 2017 at 7:45 PM, Ben Nemec  wrote:
>
>
> On 05/17/2017 10:46 AM, Jeremy Stanley wrote:
>>
>> On 2017-05-17 15:57:16 +0300 (+0300), George Shuklin wrote:
>>>
>>> There is a bug in diskimage-builder I reported it at 2017-03-10 as
>>> 'private
>>> security'. I think this bug is a medium severity.
>>>
>>> So far there was no reaction at all. I plan to change this bug to public
>>> security on next Monday. If someone is interested in bumping up CVE count
>>> for DIB, please look at
>>> https://bugs.launchpad.net/diskimage-builder/+bug/1671842 (private-walled
>>> for security group).
>>
>>
>> Thanks for the heads up! One thing we missed in the migration of DIB
>> from TripleO to Infra team governance is that the bug tracker for it
>> was still under TripleO team control (I just now leveraged my
>> OpenStack Administrator membership on LP to fix that), so the bug
>> was only visible to https://launchpad.net/~tripleo until moments
>> ago.
>>
>> That said, a "private" bug report visible to the 86 people who are
>> members of that LP team doesn't really qualify as private in my book
>> so there's probably no additional harm in just switching it to
>> public security while I work on triaging it with the DIB devs.
>> Going forward, private security bugs filed for DIB are only visible
>> to the 18 people who make up the diskimage-builder-core and
>> openstack-ci-core teams on LP, which is still more than it probably
>> should be but it's a start at least.
>
>
> Hmm, this points out a valid issue that we don't have a security group for
> tripleo at all.  We use the tripleo group to include basically all tripleo
> developers so it's definitely not appropriate for this purpose.
>
> Emilien, I think we should create a tripleo-coresec group in launchpad that
> can be used for this.  We have had tripleo-affecting security bugs in the
> past and I imagine we will again.  I'm happy to help out with that, although
> I will admit my launchpad-fu is kind of weak so I don't know off the top of
> my head how to do it.

That or re-use an existing Launchpad group used by OpenStack VMT?

fungi, thoughts?
-- 
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] [vitrage] error handling

[Yujun Zhang (ZTE)]

Brought up by a recent code review, I think it worth a thorough discussion
about the error handling rule.

I once read an article[1] from Joyent and it impressed me on the
distinguish between *Operational* errors vs. *programmer* errors. The
article is written for nodejs, but the principle also applies for other
programming language.

The basic rule recommended by Joyent is
Handling operational errors
(Not) handling programmer errors
There is also one rule in openstack style guide line[2] close to this idea.

[H201] Do not write except:, use except Exception: at the very least. When
catching an exception you should be as specific so you don’t mistakenly
catch unexpected exceptions.

I do think before we have a well designed error handling, it is better to
let it crash. It is dangerous to hide the errors and keep the system
running in undetermined states.

So the question is *what kind of operational errors are we facing in
vitrage?* I can think of something like

   1. invalid configuration file
   2. failed to communicate with data source
   3. malformed data from data source
   4. failed to execute an action
   5. ...

Maybe this could be the first step for the error handling design.

[1]: https://www.joyent.com/node-js/production/design/errors
[2]: https://docs.openstack.org/developer/hacking/

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

[openstack-dev] [infra] Removal of git-review from DIB images

[Paul Belanger]

Greetings,

Does your project use git-review on our zuul worker nodes? If so, this post is
for you.  For a long time we have installed git-review on to our worker nodes
that are used by jobs.  This also installs additional python dependencies:

  Successfully installed argparse-1.4.0 certifi-2017.4.17 chardet-3.0.3 
git-review-1.25.0 idna-2.5 requests-2.16.5 urllib3-1.21.1

Moving forward we'd like to stop adding this dependency into our base images and
have jobs themself manage installing git-review if needed.  Using codesearch.o.o
we already see some projects doing this today. If you do need it, you would add
it to your requirements.txt / test-requirements.txt files.

As such, I have proposed the removal of git-review[1] from our images.

-PB

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


__
OpenStack Development Mailing 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-dev] [Designate]

[Graham Hayes]

On 26/05/17 13:35, Andrea Frittoli wrote:
> On Thu, May 25, 2017 at 5:27 PM Carmine Annunziata
> >
> wrote:
> 
> Hi everyone,
> I integrated Designate in Openstack by devstack, now i'm using the
> new default commands like zone create/delete, etc. I got this problem:
> 
> 
> +--+---+-++++
> | id   | name  | type   
> | serial | status | action |
> 
> +--+---+-++++
> | fd80ab02-c8d7-4b06-9a4a-6026c3ca7a1c | example1.net
> . | PRIMARY | 1495725108 | ERROR  | DELETE |
> | bfd19d7d-b259-4f88-afe0-b56d21d09ebe | example2.net
> . | PRIMARY | 1495726327 | ERROR  | DELETE |
> | a33bf1fc-0112-48de-8f43-51c34845f011 | example1.com
> . | PRIMARY | 1495727006 | ERROR  | CREATE |
> 
> +--+---+-++++
> 
> 
> Hello Carmine,
> 
> I'm not an expect in Designate, but I can recommend you try to have a
> look in designate logs to see why your zone creation fails.
> If you don't find your answer there you could post relevant cli
> commands, log fragments and configuration to a publicly available place
> (e.g. [1]) and ask the ML again.
> 
> andrea

Hi Carmine,

The issue will probably be in the designate-central log, or depending on
what version of designate you are using, the designate-pool-manager or
designate-worker logs.

Thanks,

Graham


> [1] https://paste.openstack.org
> 
> 
> Same on dashboard.
> 
> Cheers,
> -- 
> Carmine
> __
> OpenStack Development Mailing 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
> 



0x23BA8E2E.asc
Description: application/pgp-keys


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

[openstack-dev] [Tripleo] deploy software on Openstack controller on the Overcloud

[Dnyaneshwar Pawar]

Hi,

I am tying to deploy a software on openstack controller on the overcloud.
One way to do this is by modifying ‘overcloud image’ so that all packages of 
our software are added to image and then run overcloud deploy.
Other way is to write heat template and puppet module which will deploy the 
required packages.

Question: Which of above two approaches is better?

Note: Configuration part of the software will be done via separate heat 
template and puppet module.


Thanks and Regards,
Dnyaneshwar
__
OpenStack Development Mailing 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][freezer] adopting oslo.context for logging debugging and tracing

[lương hữu tuấn]

Hi Renat,

Kong is going to move on with this patch and then i will continue with the
main problem of trust token in Mistral.

Br,

Tuan/Nokia

On Mon, May 29, 2017 at 9:20 AM, Renat Akhmerov 
wrote:

> Tuan,
>
> It’s ok, not always people have cycles to finish something upstream. No
> need to explain that. All I’m worried about is getting this thing done. So
> if you don’t have capacity please help transfer this work to someone else.
>
> Thanks
>
> Renat
>
> On 29 May 2017, 13:36 +0700, lương hữu tuấn ,
> wrote:
>
> Hi Doug and Renat,
>
> I totally agree with what Doug mentioned in the previous mail. In fact, my
> patch is only the used for the purpose of "implementing trust token", not
> for full refactoring mistral context. Since i do not have my capacity for
> contributing to Mistral, my commit now is for the need of Nokia in using
> token when it is expired.
>
> From very beginning, i would like to refactor mistral context to fully use
> oslo-context. But if i wanted to refactor the whole mistral context, i
> would spend my whole capacity for upstream work which is not available for
> me. By the way, thanks Doug to review it, i know all the issues in your
> comments but as i said, it was hard for me for upstream work. But i will
> re-arrange my schedule to finish as Doug commented in the patch as well as
> switching to oslo-context
>
> @Renat: I will try to refactor the whole mistral context therefore there
> will not be any roadblocks.
>
> Br,
>
> Tuan
>
> On Sat, May 27, 2017 at 2:08 AM, Vitaliy Nogin 
> wrote:
>
>> Hi Doug,
>>
>> Anyway, thank for the notification. We are really appreciated.
>>
>> Regards,
>> Vitaliy
>>
>> > 26 мая 2017 г., в 20:54, Doug Hellmann 
>> написал(а):
>> >
>> > Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100:
>> >> Hi Doug,
>> >>
>> >> Thanks for your review. Actually freezer has a separate repo for the
>> api,
>> >> it can be found here [1]. Freezer is using oslo.context since newton.
>> If
>> >> you have the time you can take a look at it and let us know if you
>> have any
>> >> comments.
>> >
>> > Ah, that explains why I couldn't find it in the freezer repo. :-)
>> >
>> > Doug
>> >
>> >>
>> >> Thanks for your help
>> >>
>> >> [1] https://github.com/openstack/freezer-api
>> >>
>> >> Best Regards,
>> >> Saad!
>> >>
>> >> On Fri, May 26, 2017 at 5:45 AM, Renat Akhmerov <
>> renat.akhme...@gmail.com>
>> >> wrote:
>> >>
>> >>> Thanks Doug. We’ll look into this.
>> >>>
>> >>> @Tuan, is there any roadblocks with the patch you’re working on? [1]
>> >>>
>> >>> [1] https://review.openstack.org/#/c/455407/
>> >>>
>> >>>
>> >>> Renat
>> >>>
>> >>> On 26 May 2017, 01:54 +0700, Doug Hellmann ,
>> wrote:
>> >>>
>> >>> The new work to add the exception information and request ID tracing
>> >>> depends on using both oslo.context and oslo.log to have all of the
>> >>> relevant pieces of information available as log messages are emitted.
>> >>>
>> >>> In the course of reviewing the "done" status for those initiatives,
>> >>> I noticed that although mistral and freezer are using oslo.log,
>> >>> neither uses oslo.context. That means neither project will get the
>> >>> extra debugging information, and neither project will see the global
>> >>> request ID in logs.
>> >>>
>> >>> I started looking at updating mistral's context to use oslo.context
>> >>> as a base class, but ran into some issues because of some extensions
>> >>> made to the existing class. I wasn't able to find where freezer is
>> >>> doing anything at all with an API request context.
>> >>>
>> >>> I'm available to help, if someone else wants to pick up the work.
>> >>>
>> >>> Doug
>> >>>
>> >>> 
>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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.op
>> enstack.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.op
>> enstack.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:unsubscrib
>> e
>> 

Re: [openstack-dev] [kolla][osprofiler][keystone][neutron][nova] osprofiler in paste deploy files

[Eduardo Gonzalez]

Hi Matt,

A), As far I can see most services with Osprofile implemented have it
enabled by default at paste-ini files except Neutron and maybe a couple
more.

B), kolla's custom keystone-paste-ini file will probably be "removed" for
Pike release, using keystone defaults with osprofile enabled. We will add
other method to customize paste-ini, ofc.

C), For now in kolla, neutron paste-ini cannot be customized by regular
methods, a quick but no good solution would be exec into container, modify
the file and restart container, or modify kolla-ansible playbooks to allow
copying your custom api-paste.ini.

Agree that option A is the best method.

FYI, at this moment there is a change under review to implement osprofile
in kolla-ansible. [0]

[0] https://review.openstack.org/#/c/455628/

Regards, Eduardo
__
OpenStack Development Mailing 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-ansible] mount ceph block from an instance

[fabrice grelaud]

Thanks for the answer.

My use case is for a file-hosting software system like « Seafile »  which can 
use a ceph backend (swift too but we don’t deploy swift on our infra).

Our network configuration of our infra is identical as your OSA documentation. 
So, on our compute node we have two bonding interface (bond0 and bond1).
The ceph vlan is actually propagate on bond0 (where is attach br-storage) to 
have ceph backend for our openstack.
And on bond1, among other, we have br-vlan for ours vlans providers.

If i understood correctly, the solution is to propagate too on our switch the 
ceph vlan on bond1, and create by neutron the provider network to be reachable 
in the tenant by our file-hosting software.

For security issues, using neutron rbac tool to share only this provider 
network to the tenant in question, could be sufficient ?

I’m all ears ;-) if you have another alternative.

Regards,
Fabrice


> Le 25 mai 2017 à 14:01, Jean-Philippe Evrard 
>  a écrit :
> 
> I doubt many people have tried this, because 1) cinder/nova/glance probably 
> do the job well in a multi-tenant fashion 2) you’re poking holes into your 
> ceph cluster security.
> 
> Anyway, if you still want it, you would need (I guess) have to create a 
> provider network that will be allowed to access your ceph network.
> 
> You can either route it from your current public network, or create another 
> network. It’s 100% up to you, and not osa specific.
> 
> Best regards,
> JP
> 
> On 24/05/2017, 15:02, "fabrice grelaud"  wrote:
> 
>Hi osa team,
> 
>i have a multimode openstack-ansible deployed, ocata 15.1.3, with ceph as 
> backend for cinder (with our own ceph infra).
> 
>After create an instance with root volume, i would like to mount a ceph 
> block or cephfs directly to the vm (not a cinder volume). So i want to attach 
> a new interface to the vm that is in the ceph vlan.
>How can i do that ?
> 
>We have our ceph vlan propagated on bond0 interface (bond0.xxx and 
> br-storage configured as documented) for openstack infrastructure.
> 
>Should i have to propagate this vlan on the bond1 interface where my 
> br-vlan is attach ?
>Should i have to use the existing br-storage where the ceph vlan is 
> already propagated (bond0.xxx) ? And how i create the ceph vlan network in 
> neutron (by neutron directly or by horizon) ?
> 
>Has anyone ever experienced this ?
> 
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> OpenStack Development Mailing 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] [kolla][osprofiler][keystone][neutron][nova] osprofiler in paste deploy files

[Matthieu Simonin]

Hello, 

I'd like to have more insight on OSProfiler support in paste-deploy files as it 
seems not similar across projects.
As a result, the way you can enable it on Kolla side differs. Here are some 
examples:

a) Nova paste.ini already contains OSProfiler middleware[1].

b) Keystone paste.ini doesn't contain OSProfiler but the file is exposed in 
Kolla-ansible. 
Thus it can be overwritten[2] by providing an alternate paste file using a 
node_custom_config directory.

c) Neutron paste.ini doesn't contain OSProfiler middleware[3]. For devstack, a 
hook can reconfigure the file at deploy time[4].
For Kolla, it seems that the only solution right now is to rebuild the whole 
docker image.

As a user of Kolla and OSprofiler a) is the most convenient thing. 

Regarding b) and c), is it a deliberate choice to ship the paste deploy files 
without OSProfiler middleware? 

Do you think we could converge ? ideally having a) for every API services ?

Best,

Matt

[1]: 
https://github.com/openstack/nova/blob/0d31fb303e07b7ed9f55b9c823b43e6db5153ee6/etc/nova/api-paste.ini#L29-L37
[2]: 
https://github.com/openstack/kolla-ansible/blob/fe61612ec6db469cccf2d2b4f0bd404ad4ced112/ansible/roles/keystone/tasks/config.yml#L119
[3]: 
https://github.com/openstack/neutron/blob/e4557a7793fbf3461bfae36ead41ee4d349920ab/neutron/tests/contrib/hooks/osprofiler
[4]: 
https://github.com/openstack/neutron/blob/e4557a7793fbf3461bfae36ead41ee4d349920ab/etc/api-paste.ini#L6-L9

__
OpenStack Development Mailing 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] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

We will not hold the Vitrage weekly IRC meeting this week, as many Vitrage 
contributors will be on vacation.
We will meet again next week, on June 7th.

Thanks,
Ifat.

__
OpenStack Development Mailing 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][freezer] adopting oslo.context for logging debugging and tracing

[Renat Akhmerov]

Tuan,

It’s ok, not always people have cycles to finish something upstream. No need to 
explain that. All I’m worried about is getting this thing done. So if you don’t 
have capacity please help transfer this work to someone else.

Thanks

Renat

On 29 May 2017, 13:36 +0700, lương hữu tuấn , wrote:
> Hi Doug and Renat,
>
> I totally agree with what Doug mentioned in the previous mail. In fact, my 
> patch is only the used for the purpose of "implementing trust token", not for 
> full refactoring mistral context. Since i do not have my capacity for 
> contributing to Mistral, my commit now is for the need of Nokia in using 
> token when it is expired.
>
> From very beginning, i would like to refactor mistral context to fully use 
> oslo-context. But if i wanted to refactor the whole mistral context, i would 
> spend my whole capacity for upstream work which is not available for me. By 
> the way, thanks Doug to review it, i know all the issues in your comments but 
> as i said, it was hard for me for upstream work. But i will re-arrange my 
> schedule to finish as Doug commented in the patch as well as switching to 
> oslo-context
>
> @Renat: I will try to refactor the whole mistral context therefore there will 
> not be any roadblocks.
>
> Br,
>
> Tuan
>
> > On Sat, May 27, 2017 at 2:08 AM, Vitaliy Nogin  wrote:
> > > Hi Doug,
> > >
> > > Anyway, thank for the notification. We are really appreciated.
> > >
> > > Regards,
> > > Vitaliy
> > >
> > > > 26 мая 2017 г., в 20:54, Doug Hellmann  
> > > > написал(а):
> > > >
> > > > Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100:
> > > >> Hi Doug,
> > > >>
> > > >> Thanks for your review. Actually freezer has a separate repo for the 
> > > >> api,
> > > >> it can be found here [1]. Freezer is using oslo.context since newton. 
> > > >> If
> > > >> you have the time you can take a look at it and let us know if you 
> > > >> have any
> > > >> comments.
> > > >
> > > > Ah, that explains why I couldn't find it in the freezer repo. :-)
> > > >
> > > > Doug
> > > >
> > > >>
> > > >> Thanks for your help
> > > >>
> > > >> [1] https://github.com/openstack/freezer-api
> > > >>
> > > >> Best Regards,
> > > >> Saad!
> > > >>
> > > >> On Fri, May 26, 2017 at 5:45 AM, Renat Akhmerov 
> > > >> 
> > > >> wrote:
> > > >>
> > > >>> Thanks Doug. We’ll look into this.
> > > >>>
> > > >>> @Tuan, is there any roadblocks with the patch you’re working on? [1]
> > > >>>
> > > >>> [1] https://review.openstack.org/#/c/455407/
> > > >>>
> > > >>>
> > > >>> Renat
> > > >>>
> > > >>> On 26 May 2017, 01:54 +0700, Doug Hellmann , 
> > > >>> wrote:
> > > >>>
> > > >>> The new work to add the exception information and request ID tracing
> > > >>> depends on using both oslo.context and oslo.log to have all of the
> > > >>> relevant pieces of information available as log messages are emitted.
> > > >>>
> > > >>> In the course of reviewing the "done" status for those initiatives,
> > > >>> I noticed that although mistral and freezer are using oslo.log,
> > > >>> neither uses oslo.context. That means neither project will get the
> > > >>> extra debugging information, and neither project will see the global
> > > >>> request ID in logs.
> > > >>>
> > > >>> I started looking at updating mistral's context to use oslo.context
> > > >>> as a base class, but ran into some issues because of some extensions
> > > >>> made to the existing class. I wasn't able to find where freezer is
> > > >>> doing anything at all with an API request context.
> > > >>>
> > > >>> I'm available to help, if someone else wants to pick up the work.
> > > >>>
> > > >>> 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
> > > >>>
> > > >>>
> > > >>> __
> > > >>> OpenStack Development Mailing 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: 

Re: [openstack-dev] [TripleO] Undercloud backup and restore

[Shinobu Kinjo]

Here is feedback from the customer.

Following the guide [1], undercloud restoration was not succeeded.

Swift objects could haven't been downloaded after restoration even
though they followed all procedures during backing up / restoring
their system described in [1].

Since that, I'm not 100% sure if `tar -czf` is good enough to take a
backup of the system or not.

It would be great help to do dry-run against backed up data so that we
can make sure that backed up data is completely fine.

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/back_up_and_restore_red_hat_enterprise_linux_openstack_platform/back_up_and_restore_the_undercloud


On Wed, May 24, 2017 at 4:26 PM, Carlos Camacho Gonzalez
 wrote:
> Hey folks,
>
> Based on what we discussed yesterday in the TripleO weekly team meeting,
> I'll like to propose a blueprint to create 2 features, basically to backup
> and restore the Undercloud.
>
> I'll like to follow in the first iteration the available docs for this
> purpose [1][2].
>
> With the addition of backing up the config files on /etc/ specifically to be
> able to recover from a failed Undercloud upgrade, i.e. recover the repos
> info removed in [3].
>
> I'll like to target this for P as I think I have enough time for
> coding/testing these features.
>
> I already have created a blueprint to track this effort
> https://blueprints.launchpad.net/tripleo/+spec/undercloud-backup-restore
>
> What do you think about it?
>
> Thanks,
> Carlos.
>
> [1]:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/back_up_and_restore_red_hat_enterprise_linux_openstack_platform/restore
>
> [2]:
> https://docs.openstack.org/developer/tripleo-docs/post_deployment/backup_restore_undercloud.html
>
> [3]:
> https://docs.openstack.org/developer/tripleo-docs/installation/updating.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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] [Keystone][PublicCloud] Introducing Adjutant, an OpenStack service for signups, user invites, password reset and more!

[Adrian Turjak]

Hello OpenStack Community,

I'd like to introduce to you all a service we have developed at Catalyst
and are now ready to release to the OpenStack community in hopes that
others may find it useful. As a public cloud provider we quickly ran
into a bunch of little issues around user management, sign-ups, and
other pieces of business logic that needed to fit into how we administer
the cloud but didn't entirely make sense as additions to existing
services. There were also a lot of actions we wanted to delegate to our
customers but couldn't do without giving them too much power in
Keystone, or wanted those actions to send emails, or extend to external
non-OpenStack services.

Enter Adjutant. Adjutant (previously called StackTask) was built as a
service to allow us to create business workflows that can be exposed in
some fashion over an API. A way for us to build reusable snippets of
code that we can tie together, and a flexible and pluggable API layer we
can expose those on. We needed these to be able to talk to our external
systems, as well as our OpenStack services, and provide us some basic
steps and in some cases the ability to require approval before an action
completes. In many ways Adjutant also works as a layer around Keystone
for us to build business logic around certain things we'd like our
customers to be able to do in very limited ways.

The service itself is built on Django with Django-Rest-Framework and is
an API service with the gui component built as a ui plugin for Horizon
that allows easy integration into an OpenStack dashboard.

Adjutant, as the name implies, is a helper, not a major service, but one
that smooths some situations and an easy place to offload some admin
tasks that a customer or non-admin should be able to trigger in a more
limited way. Not only that, but it stores the history of all these
tasks, who asked for them, and when they were completed. Anything a user
does through Adjutant is stored and able to be audited, with in future
the ability for project admins to be able to audit their own tasks and
see who of their users did something.

Out of the box it provides the following functionality:

  * User invitation by users with the 'project_admin' or 'project_mod' role.
  o This will send out an email to the person you've invited with a
submission token and let them setup their password and then
grants them roles on your project. If their user exists already,
will only require confirmation and then grant roles.
  * As a 'project_admin' or 'project_mod' you can list the users with
roles on your project and edit their roles or revoke them from your
project.
  * Let non-admin users request a password reset.
  o User will be emailed a token which will let them reset their
password.
  * Basic signup
  o Let a user request a new project. Requires admin approval and
will create a new project and user, granting default roles on
the new project. Will reuse existing user if present, or send an
email to the user to setup their password.
  * Let a user update their email address.
  o Will notify old email, and send a confirmation token to the new.

Features coming in the future (most either almost done, or in prototype
stages):

  * Forced password reset
  o users with 'project_admin' or 'project_mod'**can force a
password reset for a given user in their projects
  o cloud admins can force password resets for users on their cloud.
  o changes user password to a randomly generated value and sends
user a password reset token to their email.
  o user must reset before they can log in again.
  * Quota management for your project
  o As a 'project_admin' or 'project_mod' you can request a change
in quota to a set of predefined sizes (as set in the Adjutant
conf). Sizes allows you to increase multiple related quotas at
the same time. You can move to adjacent sizes without approval a
number of times in a configurable window (days), or an admin can
approve your quota change as well.
  * Hierarchical Multi-Tenancy in a single domain environment
  o 'project_admin' to be able to create sub-projects off the
current scoped project.
  o This uses HMT properly in Keystone but does not require an admin
role and enforces a naming convention to ensure unique
namespaces per sub-projects and somewhat avoids the project name
uniqueness issues per domain. It's basically some wrapper logic
for HMT in Keystone.
  o This also adds inherited role support to the already existing
user invite and user role editing features.
  o some VERY basic sub-project quota (number of sub-projects
allowed) via metadata stored on a project in Keystone, with
quota calculations in Adjutant checking against number of
sub-projects created in your WHOLE tree within given shifting
window. 

Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing

[lương hữu tuấn]

Hi Doug and Renat,

I totally agree with what Doug mentioned in the previous mail. In fact, my
patch is only the used for the purpose of "implementing trust token", not
for full refactoring mistral context. Since i do not have my capacity for
contributing to Mistral, my commit now is for the need of Nokia in using
token when it is expired.

>From very beginning, i would like to refactor mistral context to fully use
oslo-context. But if i wanted to refactor the whole mistral context, i
would spend my whole capacity for upstream work which is not available for
me. By the way, thanks Doug to review it, i know all the issues in your
comments but as i said, it was hard for me for upstream work. But i will
re-arrange my schedule to finish as Doug commented in the patch as well as
switching to oslo-context

@Renat: I will try to refactor the whole mistral context therefore there
will not be any roadblocks.

Br,

Tuan

On Sat, May 27, 2017 at 2:08 AM, Vitaliy Nogin  wrote:

> Hi Doug,
>
> Anyway, thank for the notification. We are really appreciated.
>
> Regards,
> Vitaliy
>
> > 26 мая 2017 г., в 20:54, Doug Hellmann 
> написал(а):
> >
> > Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100:
> >> Hi Doug,
> >>
> >> Thanks for your review. Actually freezer has a separate repo for the
> api,
> >> it can be found here [1]. Freezer is using oslo.context since newton. If
> >> you have the time you can take a look at it and let us know if you have
> any
> >> comments.
> >
> > Ah, that explains why I couldn't find it in the freezer repo. :-)
> >
> > Doug
> >
> >>
> >> Thanks for your help
> >>
> >> [1] https://github.com/openstack/freezer-api
> >>
> >> Best Regards,
> >> Saad!
> >>
> >> On Fri, May 26, 2017 at 5:45 AM, Renat Akhmerov <
> renat.akhme...@gmail.com>
> >> wrote:
> >>
> >>> Thanks Doug. We’ll look into this.
> >>>
> >>> @Tuan, is there any roadblocks with the patch you’re working on? [1]
> >>>
> >>> [1] https://review.openstack.org/#/c/455407/
> >>>
> >>>
> >>> Renat
> >>>
> >>> On 26 May 2017, 01:54 +0700, Doug Hellmann ,
> wrote:
> >>>
> >>> The new work to add the exception information and request ID tracing
> >>> depends on using both oslo.context and oslo.log to have all of the
> >>> relevant pieces of information available as log messages are emitted.
> >>>
> >>> In the course of reviewing the "done" status for those initiatives,
> >>> I noticed that although mistral and freezer are using oslo.log,
> >>> neither uses oslo.context. That means neither project will get the
> >>> extra debugging information, and neither project will see the global
> >>> request ID in logs.
> >>>
> >>> I started looking at updating mistral's context to use oslo.context
> >>> as a base class, but ran into some issues because of some extensions
> >>> made to the existing class. I wasn't able to find where freezer is
> >>> doing anything at all with an API request context.
> >>>
> >>> I'm available to help, if someone else wants to pick up the work.
> >>>
> >>> 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
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing 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