Re: [openstack-dev] [Ansible][Infra] Moving ansible roles into big tent?

[Yolanda Robla Mota]

Hi
I will be interested as well. Having these playbooks in ansible can also 
be useful

in order to integrate with infra-ansible project.
I really see that collection as a valid alternative for puppet modules, 
with the advantages
that ansible can provide, but of course that moving from puppet to 
ansible on infra internally

is something that cannot be done easily, and needs a wider discussion.
If we limit the scope of the ansible playbooks only to infra components, 
I think that infra

namespace is the way to go, having an independent group of reviewers.

Best
Yolanda


El 09/09/15 a las 21:31, Ricardo Carrillo Cruz escribió:
I'm interested in ansible roles for openstack-infra, but as there is 
overlap in functionality
with the current openstack-infra puppet roles I'm not sure what's the 
stance from the

openstack-infra core members and PTL.

I think they should go to openstack-infra, since Nodepoo/Zuul/etc are 
very specific

to the OpenStack CI.

Question is if we should have a subgroup within openstack-infra 
namespace for
'stuff that is not used by OpenStack CI but interesting from CI 
perspective and/or

used by other downstream groups'.

Regards

2015-09-09 19:22 GMT+02:00 Paul Belanger >:


On Tue, Sep 08, 2015 at 06:50:38PM -0400, Emilien Macchi wrote:
>
>
> On 09/08/2015 10:57 AM, Paul Belanger wrote:
> > Greetings,
> >
> > I wanted to start a discussion about the future of ansible /
ansible roles in
> > OpenStack. Over the last week or so I've started down the
ansible path, starting
> > my first ansible role; I've started with ansible-role-nodepool[1].
> >
> > My initial question is simple, now that big tent is upon us, I
would like
> > some way to include ansible roles into the opentack git
workflow.  I first
> > thought the role might live under openstack-infra however I am
not sure that
> > is the right place.  My reason is, -infra tents to include
modules they
> > currently run under the -infra namespace, and I don't want to
start the effort
> > to convince people to migrate.
>
> I'm wondering what would be the goal of ansible-role-nodepool
and what
> it would orchestrate exactly. I did not find README that
explains it,
> and digging into the code makes me think you try to prepare nodepool
> images but I don't exactly see why.
>
> Since we already have puppet-nodepool, I'm curious about the
purpose of
> this role.
> IMHO, if we had to add such a new repo, it would be under
> openstack-infra namespace, to be consistent with other repos
> (puppet-nodepool, etc).
>
> > Another thought might be to reach out to the
os-ansible-deployment team and ask
> > how they see roles in OpenStack moving foward (mostly the
reason for this
> > email).
>
> os-ansible-deployment aims to setup OpenStack services in containers
> (LXC). I don't see relation between os-ansible-deployment (openstack
> deployment related) and ansible-role-nodepool (infra related).
>
> > Either way, I would be interested in feedback on moving
forward on this. Using
> > travis-ci and github works but OpenStack workflow is much better.
> >
> > [1] https://github.com/pabelanger/ansible-role-nodepool
> >
>
> To me, it's unclear how and why we are going to use
ansible-role-nodepool.
> Could you explain with use-case?
>
The most basic use case is managing nodepool using ansible, for
the purpose of
CI.  Bascially, rewrite puppet-nodepool using ansible.  I won't go
into the
reasoning for that, except to say people do not want to use puppet.

Regarding os-ansible-deployment, they are only related due to both
using
ansible. I wouldn't see os-ansible-deployment using the module,
however I would
hope to learn best practices and code reviews from the team.

Where ever the module lives, I would hope people interested in ansible
development would be group somehow.

> 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 Development Mailing 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] Remove MOS DEB repo from master node

[Oleg Gelbukh]

The reason people want offline deployment feature is not because of poor
connection, but rather the enterprise intranets where getting subnet with
external access sometimes is a real pain in various body parts.

--
Best regards,
Oleg Gelbukh

On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>
> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process should be the same and it should be just another
> >> repo. It doesn't mean we can't include a version on an ISO as part of a
> >> release.  Would it be better to provide the mirror on the ISO but not
> have
> >> it enabled by default for a release so that we can gather user feedback
> on
> >> this? This would include improved documentation and possibly allowing a
> user
> >> to choose their preference so we can collect metrics?
> >>
> >>
> >>> 2) Having local MOS mirror by default makes things much more
> convoluted.
> >>> We are forced to have several directories with predefined names and we
> are
> >>> forced to manage these directories in nailgun, in upgrade script, etc.
> Why?
> >>> 3) When putting MOS mirror on 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Mike Scherbakov]

I've heard very strong requirements on having all-in-one ISO, with no
Internet access installation. Why can't we make this optional in the build
system? It should be easy to implement, is not it?

We can then consider to have this as a default option.

Igor, unfortunately
>  In 2015 I believe we can ignore this "poor Internet connection"
still not exactly true for some large enterprises. Due to all the security,
etc., there are sometimes VPNs / proxies / firewalls with very low
throughput.

I found two related bugs, but I remember there were more. I'll ask guys to
provide some exact measurements they have done as well.
https://bugs.launchpad.net/fuel/+bug/1456805
https://bugs.launchpad.net/fuel/+bug/1459089 - Ryan, can you share your
network throughput measurement / estimate?

PS. I'm all for having a way in Fuel to use another packages repos, such as
CloudArchive, etc. I just want it to be flexible.
Thanks,

On Wed, Sep 9, 2015 at 10:53 PM Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>
> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process should be the same and it should be just another
> 

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

[Mike Scherbakov]

+1 to Alex & Andrey. Let's just be very careful, and consider all the use
cases before making a change.
If we can have answers to all the use cases, then we are good to go.

Important thing which we need to fix now - is to enable easy UX for making
changes to environments after deployments. Like standard configuration
management allows you to do. Namely, being able to:
a) modify params on settings tab
b) modify templates / puppet manifests
and apply changes easily to nodes.

Now, we can do b) easy and just click Deploy button or run two-three
commands [1]. a) requires changes in Nailgun code to allow post-deployment
modification of settings (we currently lock settings tab after deployment).

If we switch to package installation and this workflow (change to
manifests + 2-3 commands to rsync/run puppet on nodes) will become a
nightmare - then we'll need to figure out something else. It has to be easy
to do development and use Fuel as configuration management tool.

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

On Wed, Sep 9, 2015 at 8:01 AM Alex Schultz  wrote:

> Hey Vladimir,
>
>
>
>> Regarding plugins: plugins are welcome to install specific additional
>> DEB/RPM repos on the master node, or just configure cluster to use
>> additional onl?ne repos, where all necessary packages (including plugin
>> specific puppet manifests) are to be available. Current granular deployment
>> approach makes it easy to append specific pre-deployment tasks
>> (master/slave does not matter). Correct me if I am wrong.
>>
>>
> Don't get me wrong, I think it would be good to move to a fuel-library
> distributed via package only.  I'm bringing these points up to indicate
> that there is many other things that live in the fuel library puppet path
> than just the fuel-library package.  The plugin example is just one place
> that we will need to invest in further design and work to move to the
> package only distribution.  What I don't want is some partially executed
> work that only works for one type of deployment and creates headaches for
> the people actually having to use fuel.  The deployment engineers and
> customers who actually perform these actions should be asked about
> packaging and their comfort level with this type of requirements.  I don't
> have a complete understanding of the all the things supported today by the
> fuel plugin system so it would be nice to get someone who is more familiar
> to weigh in on this idea. Currently plugins are only rpms (no debs) and I
> don't think we are building fuel-library debs at this time either.  So
> without some work on both sides, we cannot move to just packages.
>
>
>> Regarding flexibility: having several versioned directories with puppet
>> modules on the master node, having several fuel-libraryX.Y packages
>> installed on the master node makes things "exquisitely convoluted" rather
>> than flexible. Like I said, it is flexible enough to use mcollective, plain
>> rsync, etc. if you really need to do things manually. But we have
>> convenient service (Perestroika) which builds packages in minutes if you
>> need. Moreover, In the nearest future (by 8.0) Perestroika will be
>> available as an application independent from CI. So, what is wrong with
>> building fuel-library package? What if you want to troubleshoot nova (we
>> install it using packages)? Should we also use rsync for everything else
>> like nova, mysql, etc.?
>>
>>
> Yes, we do have a service like Perestroika to build packages for us.  That
> doesn't mean everyone else does or has access to do that today.  Setting up
> a build system is a major undertaking and making that a hard requirement to
> interact with our product may be a bit much for some customers.  In
> speaking with some support folks, there are times when files have to be
> munged to get around issues because there is no package or things are on
> fire so they can't wait for a package to become available for a fix.  We
> need to be careful not to impose limits without proper justification and
> due diligence.  We already build the fuel-library package, so there's no
> reason you couldn't try switching the rsync to install the package if it's
> available on a mirror.  I just think you're going to run into the issues I
> mentioned which need to be solved before we could just mark it done.
>
> -Alex
>
>
>
>> Vladimir Kozhukalov
>>
>> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz 
>> wrote:
>>
>>> I agree that we shouldn't need to sync as we should be able to just
>>> update the fuel-library package. That being said, I think there might be a
>>> few issues with this method. The first issue is with plugins and how to
>>> properly handle the distribution of the plugins as they may also include
>>> puppet code that needs to be installed on the other nodes for a deployment.
>>> Currently I do not believe we install the plugin packages anywhere except
>>> the master and when they do get installed there may be 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Adam Heczko]

Agree, we should understand taht this is not engineering decision but
rather political/business related and fully functional ISO or ISO+some
QCOW2/whatever is a strong requirement.

regards,

A.

On Thu, Sep 10, 2015 at 8:53 AM, Yaguang Tang  wrote:

>
>
> On Thu, Sep 10, 2015 at 1:52 PM, Igor Kalnitsky 
> wrote:
>
>> Hello,
>>
>> I agree with Vladimir - the idea of online repos is a right way to
>> move. In 2015 I believe we can ignore this "poor Internet connection"
>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
>> distributives - most of them fetch needed packages from the Internet
>> during installation, not from CD/DVD. The netboot installers are
>> popular, I can't even remember when was the last time I install my
>> Debian from the DVD-1 - I use netboot installer for years.
>>
>
> You are think in a way of developers, but the fact is that Fuel are widely
> used by various  enterprises in the world wide, there are many security
> policies  for enterprise to have no internet connection.
>
>
>
>> Thanks,
>> Igor
>>
>>
>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>> >
>> >
>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
>> wrote:
>> >>
>> >>
>> >> Hey Vladimir,
>> >>
>> >>>
>> >>>
>> >
>> > 1) There won't be such things in like [1] and [2], thus less
>> > complicated flow, less errors, easier to maintain, easier to
>> understand,
>> > easier to troubleshoot
>> > 2) If one wants to have local mirror, the flow is the same as in
>> case
>> > of upstream repos (fuel-createmirror), which is clrear for a user to
>> > understand.
>> 
>> 
>>  From the issues I've seen,  fuel-createmirror isn't very straight
>>  forward and has some issues making it a bad UX.
>> >>>
>> >>>
>> >>> I'd say the whole approach of having such tool as fuel-createmirror
>> is a
>> >>> way too naive. Reliable internet connection is totally up to network
>> >>> engineering rather than deployment. Even using proxy is much better
>> that
>> >>> creating local mirror. But this discussion is totally out of the
>> scope of
>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
>> >>> straightforward (installed as rpm, has just a couple of command line
>> >>> options). The quality of this script is also out of the scope of this
>> >>> thread. BTW we have plans to improve it.
>> >>
>> >>
>> >>
>> >> Fair enough, I just wanted to raise the UX issues around these types of
>> >> things as they should go into the decision making process.
>> >>
>> >>
>> >>>
>> >
>> >
>> > Many people still associate ISO with MOS, but it is not true when
>> using
>> > package based delivery approach.
>> >
>> > It is easy to define necessary repos during deployment and thus it
>> is
>> > easy to control what exactly is going to be installed on slave
>> nodes.
>> >
>> > What do you guys think of it?
>> >
>> >
>> 
>>  Reliance on internet connectivity has been an issue since 6.1. For
>> many
>>  large users, complete access to the internet is not available or not
>>  desired.  If we want to continue down this path, we need to improve
>> the
>>  tools to setup the local mirror and properly document what
>> urls/ports/etc
>>  need to be available for the installation of openstack and any mirror
>>  creation process.  The ideal thing is to have an all-in-one CD
>> similar to a
>>  live cd that allows a user to completely try out fuel wherever they
>> want
>>  with out further requirements of internet access.  If we don't want
>> to
>>  continue with that, we need to do a better job around providing the
>> tools
>>  for a user to get up and running in a timely fashion.  Perhaps
>> providing an
>>  net-only iso and an all-included iso would be a better solution so
>> people
>>  will have their expectations properly set up front?
>> >>>
>> >>>
>> >>> Let me explain why I think having local MOS mirror by default is bad:
>> >>> 1) I don't see any reason why we should treat MOS  repo other way than
>> >>> all other online repos. A user sees on the settings tab the list of
>> repos
>> >>> one of which is local by default while others are online. It can make
>> user a
>> >>> little bit confused, can't it? A user can be also confused by the
>> fact, that
>> >>> some of the repos can be cloned locally by fuel-createmirror while
>> others
>> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
>> >>
>> >>
>> >>
>> >> I agree. The process should be the same and it should be just another
>> >> repo. It doesn't mean we can't include a version on an ISO as part of a
>> >> release.  Would it be better to provide the mirror on the ISO but not
>> have
>> >> it enabled by default for a release so that we can gather user
>> feedback on
>> >> this? This would include improved documentation and 

Re: [openstack-dev] [TripleO] Releasing tripleo-common on PyPI

[Jan Provaznik]

On 09/09/2015 12:15 PM, Dougal Matthews wrote:

Hi,

The tripleo-common library appears to be registered or PyPI but hasn't yet had
a release[1]. I am not familiar with the release process - what do we need to
do to make sure it is regularly released with other TripleO packages?

We will also want to do something similar with the new python-tripleoclient
which doesn't seem to be registered on PyPI yet at all.

Thanks,
Dougal

[1]: https://pypi.python.org/pypi/tripleo-common



Hi Dougal,
thanks for moving this forward. I've never finished the release process 
upstream, there was no interest/consumer of this lib upstream as UI/CLI 
decided to use midstream. I'm excited to see this is changing now.


Jan

__
OpenStack Development Mailing 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] questions about nova compute monitors extensions

[Hou Gang HG Liu]

Hi all,

I notice nova compute monitor now only tries to load monitors with 
namespace "nova.compute.monitors.cpu", and only one monitor in one 
namespace can be enabled(
https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py
).

Is there a plan to make MonitorHandler.NAMESPACES configurable or just 
hard code constraint as it is now? And how to make compute monitor support 
user defined as it was?

Thanks!
B.R

Hougang Liu （刘侯刚）
Developer - IBM Platform Resource Scheduler   
Systems and Technology Group

Mobile: 86-13519121974 | Phone: 86-29-68797023 | Tie-Line: 87023 陕西
省西安市高新六路42号中清大厦3层
E-mail: liuh...@cn.ibm.com  Xian, Shaanxi 
Province 710075, China 
 


__
OpenStack Development Mailing 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] trello

[Derek Higgins]

On 09/09/15 18:03, Jason Rist wrote:

On 09/09/2015 07:09 AM, Derek Higgins wrote:



On 08/09/15 16:36, Derek Higgins wrote:

Hi All,

 Some of ye may remember some time ago we used to organize TripleO
based jobs/tasks on a trello board[1], at some stage this board fell out
of use (the exact reason I can't put my finger on). This morning I was
putting a list of things together that need to be done in the area of CI
and needed somewhere to keep track of it.

I propose we get back to using this trello board and each of us add
cards at the very least for the things we are working on.

This should give each of us a lot more visibility into what is ongoing
on in the tripleo project currently, unless I hear any objections,
tomorrow I'll start archiving all cards on the boards and removing
people no longer involved in tripleo. We can then start adding items and
anybody who wants in can be added again.


This is now done, see
https://trello.com/tripleo

Please ping me on irc if you want to be added.



thanks,
Derek.

[1] - https://trello.com/tripleo

__

OpenStack Development Mailing 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

Derek - you weren't on today when I went to ping you, can you please add me so 
I can track it for RHCI purposes?


Done



Thanks!



__
OpenStack Development Mailing 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] Question about generating an oslo.utils release

[Davanum Srinivas]

Paul,

Usually there are releases every week from the oslo team. At the moment,
oslo.* releases are frozen until stable/liberty branches are cut. Usually
you can also request a new oslo library release by logging a review against
openstack/releases repository as well.

Depends-On tag works for things installed from git, NOT libraries from
pypi. hence the fail. If you want to try the change locally you can
use  LIBS_FROM_GIT config option in devstack's configuration files to
specify the library in question. However you would that once your patch has
been merged into the master branch. There are additional toggles in
devstack local.conf to do this from a pending review as well if you really
want to try it.

-- Dims

On Thu, Sep 10, 2015 at 3:53 AM, Paul Carlton  wrote:

> Hi
>
> I have an olso.utils change merged (220620
> ).  A nova change (220622
> ) depends on this.  What is the
> process for creating a new version of olso.utils?  Is this performed
> periodically by a release manager or do I need to do something myself?
>
> Incidentally, despite including a depends-on tag in my nova change's
> commit message my tests that depend on the oslo.utils change failed in CI,
> I thought the use of depends-on would cause it to load olso.utils using the
> referenced development commit?
>
> Thanks
>
> --
> Paul Carlton
> Software Engineer
> Cloud Services
> Hewlett Packard
> BUK03:T242
> Longdown Avenue
> Stoke Gifford
> Bristol BS34 8QZ
>
> Mobile:+44 (0)7768 994283
> Email:mailto:paul.carlt...@hp.com 
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 
> 1HN Registered No: 690597 England.
> The contents of this message and any attachments to it are confidential and 
> may be legally privileged. If you have received this message in error, you 
> should delete it from your system immediately and advise the sender. To any 
> recipient of this message within HP, unless otherwise stated you should 
> consider this message and attachments as "HP CONFIDENTIAL".
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing 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] [CI] [zuul] Can not vote +/-1 verified into gerrit server

[Xie, Xianshan]

Hi, all,
   In my CI environment, after submitting a patch into openstack-dev/sandbox,
the Jenkins Job can be launched automatically, and the result message of the 
job also can be posted into the gerrit server successfully.
Everything seems fine.

But in the “Verified” column, there is no verified vote, such as +1 or -1.
(patch url: https://review.openstack.org/#/c/222049/,
CI name:  Fnst OpenStackTest CI)

Although I have already added the “verified” label into the layout.yaml , under 
the check pipeline, it does not work yet.

And my configuration info is setted as follows:
Layout.yaml
---
pipelines:
  - name: check
   trigger:
 gerrit:
  - event: patchset-created
  - event: change-restored
  - event: comment-added
…
   success:
gerrit:
  verified: 1
   failure:
gerrit:
  verified: -1

jobs:
   - name: noop-check-communication
  parameter-function: reusable_node
projects:
- name: openstack-dev/sandbox
   - noop-check-communication
---


And the projects.yaml of Jenkins job:
---
- project:
name: sandbox
jobs:
  - noop-check-communication:
 node: 'devstack_slave || devstack-precise-check || d-p-c'
…
---

Could anyone help me? Thanks in advance.

Xiexs

__
OpenStack Development Mailing 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] Fwd: Re: [neutron][L3][dvr][fwaas] FWaaS

[bharath]

Hi ,

Instance creation is failing with below error from last 4 days.

*2015-09-10 02:14:00.583 WARNING neutron.plugins.ml2.drivers.mech_agent 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Attempting to bind with dead agent: 
{'binary': u'neutron-openvswitch-agent', 'des
cription': None, 'admin_state_up': True, 'heartbeat_timestamp': 
datetime.datetime(2015, 9, 10, 9, 6, 57), 'alive': False, 'topic': 
u'N/A', 'host': u'ci-jslave-base', 'agent_type': u'Open vSwitch agent', 
'created_at': datetime.datetime(2
015, 9, 10, 9, 4, 57), 'started_at': datetime.datetime(2015, 9, 10, 9, 
6, 57), 'id': u'aa9098fe-c412-449e-b979-1f5ab46c3c1d', 'configurations': 
{u'in_distributed_mode': False, u'arp_responder_enabled': False, 
u'tunneling_ip': u'192.168.
30.41', u'devices': 0, u'log_agent_heartbeats': False, u'l2_population': 
False, u'tunnel_types': [u'vxlan'], u'enable_distributed_routing': 
False, u'bridge_mappings': {u'ext': u'br-ext', u'mng': u'br-mng'}}}*
2015-09-10 02:14:00.583 DEBUG neutron.plugins.ml2.drivers.mech_agent 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Attempting to bind port 
6733610d-e7dc-4ecd-a810-b2b791af9b97 on network c6fb26cc-96
1e-4f38-bf40-bfc72cc59f67 from (pid=25516) bind_port 
/opt/stack/neutron/neutron/plugins/ml2/drivers/mech_agent.py:60
*2015-09-10 02:14:00.588 ERROR neutron.plugins.ml2.managers 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Failed to bind port 
6733610d-e7dc-4ecd-a810-b2b791af9b97 on host ci-jslave-base
2015-09-10 02:14:00.588 ERROR neutron.plugins.ml2.managers 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Failed to bind port 
6733610d-e7dc-4ecd-a810-b2b791af9b97 on host ci-jslave-base*
2015-09-10 02:14:00.608 DEBUG neutron.plugins.ml2.db 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] For port 
6733610d-e7dc-4ecd-a810-b2b791af9b97, host ci-jslave-base, cleared 
binding levels from (pi
d=25516) clear_binding_levels 
/opt/stack/neutron/neutron/plugins/ml2/db.py:189
2015-09-10 02:14:00.608 DEBUG neutron.plugins.ml2.db 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Attempted to set empty binding levels 
from (pid=25516) set_binding_levels /opt/stack/neutron/neutro

n/plugins/ml2/db.py:164


Recent commit seems to be broken this.


During stacking i am getting below error , but i dont know whether its 
related to above issue or not


2015-09-09 15:18:48.658 | ERROR: openstack 'module' object has no attribute 
'UpdateDataSource'


would love some help on this issue

Thanks,
bharath
__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Yaguang Tang]

On Thu, Sep 10, 2015 at 1:52 PM, Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>

You are think in a way of developers, but the fact is that Fuel are widely
used by various  enterprises in the world wide, there are many security
policies  for enterprise to have no internet connection.



> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process should be the same and it should be just another
> >> repo. It doesn't mean we can't include a version on an ISO as part of a
> >> release.  Would it be better to provide the mirror on the ISO but not
> have
> >> it enabled by default for a release so that we can gather user feedback
> on
> >> this? This would include improved documentation and possibly allowing a
> user
> >> to choose their preference so we can collect metrics?
> >>
> >>
> >>> 2) Having local MOS mirror by default makes things much more
> convoluted.
> >>> We are forced to have several directories with predefined names and we
> are
> >>> forced to manage these directories in nailgun, in upgrade script, etc.
> Why?
> >>> 3) When putting MOS mirror on ISO, we make people think that ISO is

Re: [openstack-dev] [Heat] Multi Node Stack - keystone federation

[SHTILMAN, Tomer (Tomer)]

>>On 09/09/15 04:10, SHTILMAN, Tomer (Tomer) wrote:
>> We are currently building in our lab multi cloud setup with keystone 
>> federation and I will check if my understating is correct, I am 
>> planning for propose a BP for this once will be clear
> On 09/09/15 Zane wrote:
>There was further interest in this at the IRC meeting today (from Daniel 
>Gonzalez), so I raised this blueprint:
>
>https://blueprints.launchpad.net/heat/+spec/multi-cloud-federation
>
>I left the Drafter and Assignee fields blank, so whoever starts working on the 
>spec and the code, respectively, should put their names in those fields. If 
>you see someone else's name there, you should co-ordinate with them to avoid 
>double-handling.
>
>cheers,
>Zane.
>
Hi Zane
Couldn't change the assignee and the drafter on this from some reason can you 
please assign me on this BP

__
OpenStack Development Mailing 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] Install fuel-libraryX.Y as a package on slave nodes

[Oleg Gelbukh]

Alex,

I absolutely understand the point you are making about need for deployment
engineers to modify things 'on the fly' in customer environment. It's makes
things really flexible and lowers the entry barrier for sure.

However, I would like to note that in my opinion this kind on 'monkey
patching' is actually a bad practice for any environments other than dev
ones. It immediately leads to emergence of unsupportable frankenclouds. I
would greet any modification to the workflow that will discourage people
from doing that.

--
Best regards,
Oleg Gelbukh

On Wed, Sep 9, 2015 at 5:56 PM, Alex Schultz  wrote:

> Hey Vladimir,
>
>
>
>> Regarding plugins: plugins are welcome to install specific additional
>> DEB/RPM repos on the master node, or just configure cluster to use
>> additional onl?ne repos, where all necessary packages (including plugin
>> specific puppet manifests) are to be available. Current granular deployment
>> approach makes it easy to append specific pre-deployment tasks
>> (master/slave does not matter). Correct me if I am wrong.
>>
>>
> Don't get me wrong, I think it would be good to move to a fuel-library
> distributed via package only.  I'm bringing these points up to indicate
> that there is many other things that live in the fuel library puppet path
> than just the fuel-library package.  The plugin example is just one place
> that we will need to invest in further design and work to move to the
> package only distribution.  What I don't want is some partially executed
> work that only works for one type of deployment and creates headaches for
> the people actually having to use fuel.  The deployment engineers and
> customers who actually perform these actions should be asked about
> packaging and their comfort level with this type of requirements.  I don't
> have a complete understanding of the all the things supported today by the
> fuel plugin system so it would be nice to get someone who is more familiar
> to weigh in on this idea. Currently plugins are only rpms (no debs) and I
> don't think we are building fuel-library debs at this time either.  So
> without some work on both sides, we cannot move to just packages.
>
>
>> Regarding flexibility: having several versioned directories with puppet
>> modules on the master node, having several fuel-libraryX.Y packages
>> installed on the master node makes things "exquisitely convoluted" rather
>> than flexible. Like I said, it is flexible enough to use mcollective, plain
>> rsync, etc. if you really need to do things manually. But we have
>> convenient service (Perestroika) which builds packages in minutes if you
>> need. Moreover, In the nearest future (by 8.0) Perestroika will be
>> available as an application independent from CI. So, what is wrong with
>> building fuel-library package? What if you want to troubleshoot nova (we
>> install it using packages)? Should we also use rsync for everything else
>> like nova, mysql, etc.?
>>
>>
> Yes, we do have a service like Perestroika to build packages for us.  That
> doesn't mean everyone else does or has access to do that today.  Setting up
> a build system is a major undertaking and making that a hard requirement to
> interact with our product may be a bit much for some customers.  In
> speaking with some support folks, there are times when files have to be
> munged to get around issues because there is no package or things are on
> fire so they can't wait for a package to become available for a fix.  We
> need to be careful not to impose limits without proper justification and
> due diligence.  We already build the fuel-library package, so there's no
> reason you couldn't try switching the rsync to install the package if it's
> available on a mirror.  I just think you're going to run into the issues I
> mentioned which need to be solved before we could just mark it done.
>
> -Alex
>
>
>
>> Vladimir Kozhukalov
>>
>> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz 
>> wrote:
>>
>>> I agree that we shouldn't need to sync as we should be able to just
>>> update the fuel-library package. That being said, I think there might be a
>>> few issues with this method. The first issue is with plugins and how to
>>> properly handle the distribution of the plugins as they may also include
>>> puppet code that needs to be installed on the other nodes for a deployment.
>>> Currently I do not believe we install the plugin packages anywhere except
>>> the master and when they do get installed there may be some post-install
>>> actions that are only valid for the master.  Another issue is being
>>> flexible enough to allow for deployment engineers to make custom changes
>>> for a given environment.  Unless we can provide an improved process to
>>> allow for people to provide in place modifications for an environment, we
>>> can't do away with the rsync.
>>>
>>> If we want to go completely down the package route (and we probably
>>> should), we need to make sure 

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

[Sergii Golovatiuk]

Oleg,

Alex gave a perfect example regarding support folks when they need to fix
something really quick. It's client's choice what to patch or not. You may
like it or not, but it's client's choice.

On 10 Sep 2015, at 09:33, Oleg Gelbukh  wrote:

Alex,

I absolutely understand the point you are making about need for deployment
engineers to modify things 'on the fly' in customer environment. It's makes
things really flexible and lowers the entry barrier for sure.

However, I would like to note that in my opinion this kind on 'monkey
patching' is actually a bad practice for any environments other than dev
ones. It immediately leads to emergence of unsupportable frankenclouds. I
would greet any modification to the workflow that will discourage people
from doing that.

--
Best regards,
Oleg Gelbukh

On Wed, Sep 9, 2015 at 5:56 PM, Alex Schultz  wrote:

> Hey Vladimir,
>
>
>
>> Regarding plugins: plugins are welcome to install specific additional
>> DEB/RPM repos on the master node, or just configure cluster to use
>> additional onl?ne repos, where all necessary packages (including plugin
>> specific puppet manifests) are to be available. Current granular deployment
>> approach makes it easy to append specific pre-deployment tasks
>> (master/slave does not matter). Correct me if I am wrong.
>>
>>
> Don't get me wrong, I think it would be good to move to a fuel-library
> distributed via package only.  I'm bringing these points up to indicate
> that there is many other things that live in the fuel library puppet path
> than just the fuel-library package.  The plugin example is just one place
> that we will need to invest in further design and work to move to the
> package only distribution.  What I don't want is some partially executed
> work that only works for one type of deployment and creates headaches for
> the people actually having to use fuel.  The deployment engineers and
> customers who actually perform these actions should be asked about
> packaging and their comfort level with this type of requirements.  I don't
> have a complete understanding of the all the things supported today by the
> fuel plugin system so it would be nice to get someone who is more familiar
> to weigh in on this idea. Currently plugins are only rpms (no debs) and I
> don't think we are building fuel-library debs at this time either.  So
> without some work on both sides, we cannot move to just packages.
>
>
>> Regarding flexibility: having several versioned directories with puppet
>> modules on the master node, having several fuel-libraryX.Y packages
>> installed on the master node makes things "exquisitely convoluted" rather
>> than flexible. Like I said, it is flexible enough to use mcollective, plain
>> rsync, etc. if you really need to do things manually. But we have
>> convenient service (Perestroika) which builds packages in minutes if you
>> need. Moreover, In the nearest future (by 8.0) Perestroika will be
>> available as an application independent from CI. So, what is wrong with
>> building fuel-library package? What if you want to troubleshoot nova (we
>> install it using packages)? Should we also use rsync for everything else
>> like nova, mysql, etc.?
>>
>>
> Yes, we do have a service like Perestroika to build packages for us.  That
> doesn't mean everyone else does or has access to do that today.  Setting up
> a build system is a major undertaking and making that a hard requirement to
> interact with our product may be a bit much for some customers.  In
> speaking with some support folks, there are times when files have to be
> munged to get around issues because there is no package or things are on
> fire so they can't wait for a package to become available for a fix.  We
> need to be careful not to impose limits without proper justification and
> due diligence.  We already build the fuel-library package, so there's no
> reason you couldn't try switching the rsync to install the package if it's
> available on a mirror.  I just think you're going to run into the issues I
> mentioned which need to be solved before we could just mark it done.
>
> -Alex
>
>
>
>> Vladimir Kozhukalov
>>
>> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz 
>> wrote:
>>
>>> I agree that we shouldn't need to sync as we should be able to just
>>> update the fuel-library package. That being said, I think there might be a
>>> few issues with this method. The first issue is with plugins and how to
>>> properly handle the distribution of the plugins as they may also include
>>> puppet code that needs to be installed on the other nodes for a deployment.
>>> Currently I do not believe we install the plugin packages anywhere except
>>> the master and when they do get installed there may be some post-install
>>> actions that are only valid for the master.  Another issue is being
>>> flexible enough to allow for deployment engineers to make custom changes
>>> for a given environment.  

Re: [openstack-dev] [glance] [nova] Verification of glance images before boot

[Bhandaru, Malini K]

Brianna, I can imagine a denial of service attack by uploading images whose 
signature is invalid if we allow them to reside in Glance
In a "killed" state. This would be less of an issue "killed" images still 
consume storage quota until actually deleted.
Also given MD-5 less secure, why not have the default hash be SHA-1 or 2?
Regards
Malini

-Original Message-
From: Poulos, Brianna L. [mailto:brianna.pou...@jhuapl.edu] 
Sent: Wednesday, September 09, 2015 9:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: stuart.mcla...@hp.com
Subject: Re: [openstack-dev] [glance] [nova] Verification of glance images 
before boot

Stuart is right about what will currently happen in Nova when an image is 
downloaded, which protects against unintentional modifications to the image 
data.

What is currently being worked on is adding the ability to verify a signature 
of the checksum.  The flow of this is as follows:
1. The user creates a signature of the "checksum hash" (currently MD5) of the 
image data offline.
2. The user uploads a public key certificate, which can be used to verify the 
signature to a key manager (currently Barbican).
3. The user creates an image in glance, with signature metadata properties.
4. The user uploads the image data to glance.
5. If the signature metadata properties exist, glance verifies the signature of 
the "checksum hash", including retrieving the certificate from the key manager.
6. If the signature verification fails, glance moves the image to a killed 
state, and returns an error message to the user.
7. If the signature verification succeeds, a log message indicates that it 
succeeded, and the image upload finishes successfully.

8. Nova requests the image from glance, along with the image properties, in 
order to boot it.
9. Nova uses the signature metadata properties to verify the signature (if a 
configuration option is set).
10. If the signature verification fails, nova does not boot the image, but 
errors out.
11. If the signature verification succeeds, nova boots the image, and a log 
message notes that the verification succeeded.

Regarding what is currently in Liberty, the blueprint mentioned [1] has merged, 
and code [2] has also been merged in glance, which handles steps
1-7 of the flow above.

For steps 7-11, there is currently a nova blueprint [3], along with code [4], 
which are proposed for Mitaka.

Note that we are in the process of adding official documentation, with examples 
of creating the signature as well as the properties that need to be added for 
the image before upload.  In the meantime, there's an etherpad that describes 
how to test the signature verification functionality in Glance [5].

Also note that this is the initial approach, and there are some limitations.  
For example, ideally the signature would be based on a cryptographically secure 
(i.e. not MD5) hash of the image.  There is a spec in glance to allow this hash 
to be configurable [6].

[1]
https://blueprints.launchpad.net/glance/+spec/image-signing-and-verificatio
n-support
[2]
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb
4b04ff6e
[3] https://review.openstack.org/#/c/188874/
[4] https://review.openstack.org/#/c/189843/
[5]
https://etherpad.openstack.org/p/liberty-glance-image-signing-instructions
[6] https://review.openstack.org/#/c/191542/


Thanks,
~Brianna




On 9/9/15, 12:16 , "Nikhil Komawar"  wrote:

>That's correct.
>
>The size and the checksum are to be verified outside of Glance, in this 
>case Nova. However, you may want to note that it's not necessary that 
>all Nova virt drivers would use py-glanceclient so you would want to 
>check the download specific code in the virt driver your Nova 
>deployment is using.
>
>Having said that, essentially the flow seems appropriate. Error must be 
>raise on mismatch.
>
>The signing BP was to help prevent the compromised Glance from changing 
>the checksum and image blob at the same time. Using a digital 
>signature, you can prevent download of compromised data. However, the 
>feature has just been implemented in Glance; Glance users may take time to 
>adopt.
>
>
>
>On 9/9/15 11:15 AM, stuart.mcla...@hp.com wrote:
>>
>> The glance client (running 'inside' the Nova server) will 
>> re-calculate the checksum as it downloads the image and then compare 
>> it against the expected value. If they don't match an error will be raised.
>>
>>> How can I know that the image that a new instance is spawned from - 
>>> is actually the image that was originally registered in glance - and 
>>> has not been maliciously tampered with in some way?
>>>
>>> Is there some kind of verification that is performed against the 
>>> md5sum of the registered image in glance before a new instance is spawned?
>>>
>>> Is that done by Nova?
>>> Glance?
>>> Both? Neither?
>>>
>>> The reason I ask is some 'paranoid' security (that is their job I
>>> suppose) people have raised these questions.

[openstack-dev] [Fuel] IRC meeting today

[Mike Scherbakov]

Hi folks,
please add topics to the agenda before the meeting:
https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

It would be great to discuss:

   - Critical bugs, and the pipeline of bugs which may become Criticals
   with larger audience.
   - Current status of builds from master
   - Updates on progress in other areas not related to bugs

Thanks,


-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Adam Heczko]

Folks, what I can see is that most of you represent 'engineering' point of
view.
Way of installing OpenStack by Fuel is not 'engineering' decision - it is
political and business related decision.
I believe that possibility to get fully working / not internet dependent
ISO or ISO + some additional let's say QCOW2 disk image, holding all
necessary stuff required to deploy OpenStack is crucial determinant factor
to most of enterprise customers.
This is absolutely not internet connectivity related, this is not technical
question, we are touching philosophical approach to software distribution
approach and way of understanding of things by all kind of 'C' grade
managers.
In order OpenStack to succeed, 'no internet connectivity' approach is a
must have.
If not directly from within ISO, then we have to provide easy to use and
understand guidance how to deploy OS without any internet connectivity,
e.g. fuel-createmirror or other similar scripts.

Regards,

A.


On Thu, Sep 10, 2015 at 7:52 AM, Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>
> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process 

Re: [openstack-dev] [glance] differences between def detail() and def index() in glance/registry/api/v1/images.py

[Kuvaja, Erno]

This was the case until about two weeks ago.

Since 1.0.0 release we have been defaulting to Images API v2 instead of v1 [0].

If you want to exercise the v1 functionality from the CLI client you would need 
to specify the either environmental variable OS_IMAGE_API_VERSION=1 or use the 
command line option –os-image-api-version 1. Either case –debug can be used 
with glanceclient to provide detailed information about where the request is 
being sent and what the responses are.

If you haven’t moved to the latest client yet, forget about the above apart 
from the –debug part.

[0] 
https://github.com/openstack/python-glanceclient/blob/master/doc/source/index.rst


-  Erno

From: Fei Long Wang [mailto:feil...@catalyst.net.nz]
Sent: Thursday, September 10, 2015 1:04 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] differences between def detail() and def 
index() in glance/registry/api/v1/images.py

I assume you're using Glance client, if so, by default, when you issuing 
command 'glance image-list', it will call /v1/images/detail instead of 
/v1/images, you can use curl or any browser http client to see the difference. 
Basically, just like the endpoint name, /v1/images/detail will give you more 
details. See below difference of their response.

Response from /v1/images/detail
{
"images": [
{
"status": "active",
"deleted_at": null,
"name": "fedora-21-atomic-3",
"deleted": false,
"container_format": "bare",
"created_at": "2015-09-03T22:56:37.00",
"disk_format": "qcow2",
"updated_at": "2015-09-03T23:00:15.00",
"min_disk": 0,
"protected": false,
"id": "b940521b-97ff-48d9-a22e-ecc981ec0513",
"min_ram": 0,
"checksum": "d3b3da0e07743805dcc852785c7fc258",
"owner": "5f290ac4b100440b8b4c83fce78c2db7",
"is_public": true,
"virtual_size": null,
"properties": {
"os_distro": "fedora-atomic"
},
"size": 770179072
}
]
}

Response with /v1/images
{
"images": [
{
"name": "fedora-21-atomic-3",
"container_format": "bare",
"disk_format": "qcow2",
"checksum": "d3b3da0e07743805dcc852785c7fc258",
"id": "b940521b-97ff-48d9-a22e-ecc981ec0513",
"size": 770179072
}
]
}
On 10/09/15 11:46, Su Zhang wrote:

Hello,

I am hitting an error and its trace passes def index () in 
glance/registry/api/v1/images.py.

I assume def index() is called by glance image-list. However, while testing 
glance image-list I realized that def detail() is called under 
glance/registry/api/v1/images.py instead of def index().

Could someone let me know what's the difference between the two functions? How 
can I test out def index() under glance/registry/api/v1/images.py through CLI 
or API?

Thanks,

--
Su 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


--

Cheers & Best regards,

Fei Long 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

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Igor Kalnitsky]

Mike,

> still not exactly true for some large enterprises. Due to all the security, 
> etc.,
> there are sometimes VPNs / proxies / firewalls with very low throughput.

It's their problem, and their policies. We can't and shouldn't handle
all possible cases. If some enterprise has "no Internet" policy, I bet
it won't be a problem for their IT guys to create an intranet mirror
for MOS packages. Moreover, I also bet they do have a mirror for
Ubuntu or other Linux distributive. So it basically about approach how
to consume our mirrors.

On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin  wrote:
> Folks
>
> I think, Mike is completely right here - we need an option to build
> all-in-one ISO which can be tried-out/deployed unattendedly without internet
> access. Let's let a user make a choice what he wants, not push him into
> embarassing situation. We still have many parts of Fuel which make choices
> for user that cannot be overriden. Let's not pretend that we know more than
> user does about his environment.
>
> On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
> wrote:
>>
>> The reason people want offline deployment feature is not because of poor
>> connection, but rather the enterprise intranets where getting subnet with
>> external access sometimes is a real pain in various body parts.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky 
>> wrote:
>>>
>>> Hello,
>>>
>>> I agree with Vladimir - the idea of online repos is a right way to
>>> move. In 2015 I believe we can ignore this "poor Internet connection"
>>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
>>> distributives - most of them fetch needed packages from the Internet
>>> during installation, not from CD/DVD. The netboot installers are
>>> popular, I can't even remember when was the last time I install my
>>> Debian from the DVD-1 - I use netboot installer for years.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>>> >
>>> >
>>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
>>> > wrote:
>>> >>
>>> >>
>>> >> Hey Vladimir,
>>> >>
>>> >>>
>>> >>>
>>> >
>>> > 1) There won't be such things in like [1] and [2], thus less
>>> > complicated flow, less errors, easier to maintain, easier to
>>> > understand,
>>> > easier to troubleshoot
>>> > 2) If one wants to have local mirror, the flow is the same as in
>>> > case
>>> > of upstream repos (fuel-createmirror), which is clrear for a user
>>> > to
>>> > understand.
>>> 
>>> 
>>>  From the issues I've seen,  fuel-createmirror isn't very straight
>>>  forward and has some issues making it a bad UX.
>>> >>>
>>> >>>
>>> >>> I'd say the whole approach of having such tool as fuel-createmirror
>>> >>> is a
>>> >>> way too naive. Reliable internet connection is totally up to network
>>> >>> engineering rather than deployment. Even using proxy is much better
>>> >>> that
>>> >>> creating local mirror. But this discussion is totally out of the
>>> >>> scope of
>>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
>>> >>> straightforward (installed as rpm, has just a couple of command line
>>> >>> options). The quality of this script is also out of the scope of this
>>> >>> thread. BTW we have plans to improve it.
>>> >>
>>> >>
>>> >>
>>> >> Fair enough, I just wanted to raise the UX issues around these types
>>> >> of
>>> >> things as they should go into the decision making process.
>>> >>
>>> >>
>>> >>>
>>> >
>>> >
>>> > Many people still associate ISO with MOS, but it is not true when
>>> > using
>>> > package based delivery approach.
>>> >
>>> > It is easy to define necessary repos during deployment and thus it
>>> > is
>>> > easy to control what exactly is going to be installed on slave
>>> > nodes.
>>> >
>>> > What do you guys think of it?
>>> >
>>> >
>>> 
>>>  Reliance on internet connectivity has been an issue since 6.1. For
>>>  many
>>>  large users, complete access to the internet is not available or not
>>>  desired.  If we want to continue down this path, we need to improve
>>>  the
>>>  tools to setup the local mirror and properly document what
>>>  urls/ports/etc
>>>  need to be available for the installation of openstack and any
>>>  mirror
>>>  creation process.  The ideal thing is to have an all-in-one CD
>>>  similar to a
>>>  live cd that allows a user to completely try out fuel wherever they
>>>  want
>>>  with out further requirements of internet access.  If we don't want
>>>  to
>>>  continue with that, we need to do a better job around providing the
>>>  tools
>>>  for a user to get up and running in a timely fashion.  Perhaps
>>>  providing an
>>>  

Re: [openstack-dev] [neutron] RFE process question

[Gal Sagie]

Hi James,

I think that https://review.openstack.org/#/c/216021/ might be what you are
looking for.
Please review and see that it fits your requierment.
Hopefully this gets approved for next release and i can start working on
it, if you would like to join
and contribute (or anyone in your team) i would love any help on that.

Thanks
Gal.

On Thu, Sep 10, 2015 at 8:59 AM, Armando M.  wrote:

>
> On 10 September 2015 at 11:04, James Dempsey 
> wrote:
>
>> Greetings Devs,
>>
>> I'm very excited about the new RFE process and thought I'd test it by
>> requesting a feature that is very often requested by my users[1].
>>
>> There are some great docs out there about how to submit an RFE, but I
>> don't know what should happen after the submission to launchpad. My RFE
>> bug seems to have been untouched for a month and I'm unsure if I've done
>> something wrong. So, here are a few questions that I have.
>>
>>
>> 1. Should I be following up on the dev list to ask for someone to look
>> at my RFE bug?
>> 2. How long should I expect it to take to have my RFE acknowledged?
>> 3. As an operator, I'm a bit ignorant as to whether or not there are
>> times during the release cycle during which there simply won't be
>> bandwidth to consider RFE bugs.
>> 4. Should I be doing anything else?
>>
>> Would love some guidance.
>>
>
> you did nothing wrong, the team was simply busy going through the existing
> schedule. Having said that, you could have spared a few more words on the
> use case and what you mean by annotations.
>
> I'll follow up on the RFE for more questions.
>
> Cheers,
> Armando
>
>
>>
>> Cheers,
>> James
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1483480
>>
>> --
>> James Dempsey
>> Senior Cloud Engineer
>> Catalyst IT Limited
>> +64 4 803 2264
>> --
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Best Regards ,

The G.
__
OpenStack Development Mailing 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] Question about generating an oslo.utils release

[Paul Carlton]

Hi

I have an olso.utils change merged (220620 
).  A nova change (220622 
) depends on this.  What is 
the process for creating a new version of olso.utils?  Is this performed 
periodically by a release manager or do I need to do something myself?


Incidentally, despite including a depends-on tag in my nova change's 
commit message my tests that depend on the oslo.utils change failed in 
CI, I thought the use of depends-on would cause it to load olso.utils 
using the referenced development commit?


Thanks

--
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:+44 (0)7768 994283
Email:mailto:paul.carlt...@hp.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN 
Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be 
legally privileged. If you have received this message in error, you should delete it from 
your system immediately and advise the sender. To any recipient of this message within 
HP, unless otherwise stated you should consider this message and attachments as "HP 
CONFIDENTIAL".

__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Folks

I think, Mike is completely right here - we need an option to build
all-in-one ISO which can be tried-out/deployed unattendedly without
internet access. Let's let a user make a choice what he wants, not push him
into embarassing situation. We still have many parts of Fuel which make
choices for user that cannot be overriden. Let's not pretend that we know
more than user does about his environment.

On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
wrote:

> The reason people want offline deployment feature is not because of poor
> connection, but rather the enterprise intranets where getting subnet with
> external access sometimes is a real pain in various body parts.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky 
> wrote:
>
>> Hello,
>>
>> I agree with Vladimir - the idea of online repos is a right way to
>> move. In 2015 I believe we can ignore this "poor Internet connection"
>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
>> distributives - most of them fetch needed packages from the Internet
>> during installation, not from CD/DVD. The netboot installers are
>> popular, I can't even remember when was the last time I install my
>> Debian from the DVD-1 - I use netboot installer for years.
>>
>> Thanks,
>> Igor
>>
>>
>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>> >
>> >
>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
>> wrote:
>> >>
>> >>
>> >> Hey Vladimir,
>> >>
>> >>>
>> >>>
>> >
>> > 1) There won't be such things in like [1] and [2], thus less
>> > complicated flow, less errors, easier to maintain, easier to
>> understand,
>> > easier to troubleshoot
>> > 2) If one wants to have local mirror, the flow is the same as in
>> case
>> > of upstream repos (fuel-createmirror), which is clrear for a user to
>> > understand.
>> 
>> 
>>  From the issues I've seen,  fuel-createmirror isn't very straight
>>  forward and has some issues making it a bad UX.
>> >>>
>> >>>
>> >>> I'd say the whole approach of having such tool as fuel-createmirror
>> is a
>> >>> way too naive. Reliable internet connection is totally up to network
>> >>> engineering rather than deployment. Even using proxy is much better
>> that
>> >>> creating local mirror. But this discussion is totally out of the
>> scope of
>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
>> >>> straightforward (installed as rpm, has just a couple of command line
>> >>> options). The quality of this script is also out of the scope of this
>> >>> thread. BTW we have plans to improve it.
>> >>
>> >>
>> >>
>> >> Fair enough, I just wanted to raise the UX issues around these types of
>> >> things as they should go into the decision making process.
>> >>
>> >>
>> >>>
>> >
>> >
>> > Many people still associate ISO with MOS, but it is not true when
>> using
>> > package based delivery approach.
>> >
>> > It is easy to define necessary repos during deployment and thus it
>> is
>> > easy to control what exactly is going to be installed on slave
>> nodes.
>> >
>> > What do you guys think of it?
>> >
>> >
>> 
>>  Reliance on internet connectivity has been an issue since 6.1. For
>> many
>>  large users, complete access to the internet is not available or not
>>  desired.  If we want to continue down this path, we need to improve
>> the
>>  tools to setup the local mirror and properly document what
>> urls/ports/etc
>>  need to be available for the installation of openstack and any mirror
>>  creation process.  The ideal thing is to have an all-in-one CD
>> similar to a
>>  live cd that allows a user to completely try out fuel wherever they
>> want
>>  with out further requirements of internet access.  If we don't want
>> to
>>  continue with that, we need to do a better job around providing the
>> tools
>>  for a user to get up and running in a timely fashion.  Perhaps
>> providing an
>>  net-only iso and an all-included iso would be a better solution so
>> people
>>  will have their expectations properly set up front?
>> >>>
>> >>>
>> >>> Let me explain why I think having local MOS mirror by default is bad:
>> >>> 1) I don't see any reason why we should treat MOS  repo other way than
>> >>> all other online repos. A user sees on the settings tab the list of
>> repos
>> >>> one of which is local by default while others are online. It can make
>> user a
>> >>> little bit confused, can't it? A user can be also confused by the
>> fact, that
>> >>> some of the repos can be cloned locally by fuel-createmirror while
>> others
>> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
>> >>
>> >>
>> >>
>> >> I agree. The process should be the same and it should be just another
>> >> repo. It doesn't mean we can't include a 

[openstack-dev] Instance STOPS/STARTS while taking snapshot

[James Galvin]

Openstack Kilo release Ceph storage backend

I have run into an issue lately where I create a snapshot of a running 
instance, while the snapshot state is "image pending upload" And "Queued" state 
in the image service, I cant access my Instance

I cant access it via the console, ssh and I ran a continuous ping to the 
floating IP and it times out, but the instance still shows running on the 
dashboard

As soon as the instance state is "Image uploading" and in the image service 
"saving" The instance becomes available again,

Is this a known issue? All of this is done via Horizon dashboard

I can see the following in the logs on the compute:

2015-09-09 14:33:39.265 23261 INFO nova.compute.manager 
[req-0252f823-73f5-4c37-aa86-efbe6536e4f6 d2b1cc9566d44a909de46689569118e3 
3b5e03b8a83e44dd9a7140d868d28a9e - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] instance snapshotting 2015-09-09 
14:33:39.877 23261 INFO nova.compute.manager 
[req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] VM Paused (Lifecycle Event) 2015-09-09 
14:33:40.049 23261 INFO nova.compute.manager 
[req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] During sync_power_state the instance has 
a pending task (image_snapshot). Skip. 2015-09-09 14:33:50.756 23261 INFO 
nova.virt.libvirt.driver [req-0252f823-73f5-4c37-aa86-efbe6536e4f6 
d2b1cc9566d44a909de46689569118e3 3b5e03b8a83e44dd9a7140d868d28a9e - - -] 
[instance: a0e855e5-c205-4d61-bd48-99384d6310f5] Beginning cold snapshot 
process 2015-09-09 14:33:50.759 23261 INFO nova.compute.manager 
[req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] VM Stopped (Lifecycle Event) 2015-09-09 
14:33:50.939 23261 INFO nova.compute.manager 
[req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] During sync_power_state the instance has 
a pending task (image_snapshot). Skip. 2015-09-09 14:35:57.831 23261 INFO 
nova.compute.manager [req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] 
[instance: a0e855e5-c205-4d61-bd48-99384d6310f5] VM Started (Lifecycle Event) 
2015-09-09 14:35:57.990 23261 INFO nova.compute.manager 
[req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] During sync_power_state the instance has 
a pending task (image_pending_upload). Skip. 2015-09-09 14:35:57.991 23261 INFO 
nova.compute.manager [req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] 
[instance: a0e855e5-c205-4d61-bd48-99384d6310f5] VM Resumed (Lifecycle Event) 
2015-09-09 14:35:58.151 23261 INFO nova.compute.manager 
[req-1a3446d4-c183-4729-86b3-d63e15fe38d7 - - - - -] [instance: 
a0e855e5-c205-4d61-bd48-99384d6310f5] During sync_power_state the instance has 
a pending task (image_pending_upload). Skip. 2015-09-09 14:35:58.498 23261 INFO 
nova.virt.libvirt.driver [req-0252f823-73f5-4c37-aa86-efbe6536e4f6 
d2b1cc9566d44a909de46689569118e3 3b5e03b8a83e44dd9a7140d868d28a9e - - -] 
[instance: a0e855e5-c205-4d61-bd48-99384d6310f5] Snapshot extracted, beginning 
image upload

Any help with this would be appreciated :)

Thanks
James
This e-mail contains confidential information or information belonging to 
Servecentric Ltd and is intended solely for the addressee(s). The unauthorized 
disclosure, use, dissemination or copy (either in whole or in part) of this 
e-mail, or any information it contains, is prohibited. Any views or opinions 
presented are solely those of the author and do not necessarily represent those 
of Servecentric Ltd. E-mails are susceptible to alteration and their integrity 
cannot be guaranteed. Servecentric shall not be liable for the contents of this 
e-mail if modified or falsified. If you are not the intended recipient of this 
e-mail, please delete it immediately from your system and notify the sender of 
the wrong delivery and of the email's deletion.
__
OpenStack Development Mailing 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] Feature Freeze Exception proposal

[Bhandaru, Malini K]

Thank you! -- Malini

-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: Wednesday, September 09, 2015 8:06 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception proposal

FYI, this was granted FFE.

On 9/8/15 11:02 AM, Nikhil Komawar wrote:
> Malini,
>
> Your note on the etherpad [1] went unnoticed as we had that sync on 
> Friday outside of our regular meeting and weekly meeting agenda 
> etherpad was not fit for discussion purposes.
>
> It would be nice if you all can update & comment on the spec, ref. the 
> note or have someone send a relative email here that explains the 
> redressal of the issues raised on the spec and during Friday sync [2].
>
> [1] https://etherpad.openstack.org/p/glance-team-meeting-agenda
> [2]
> http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstac
> k-glance.2015-09-04.log.html#t2015-09-04T14:29:47
>
> On 9/5/15 4:40 PM, Bhandaru, Malini K wrote:
>> Thank you Nikhil and Glance team on the FFE consideration.
>> We are committed to making the revisions per suggestion and separately seek 
>> help from the Flavio, Sabari, and Harsh.
>> Regards
>> Malini, Kent, and Jakub
>>
>>
>> -Original Message-
>> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
>> Sent: Friday, September 04, 2015 9:44 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
>> proposal
>>
>> Hi Malini et.al.,
>>
>> We had a sync up earlier today on this topic and a few items were discussed 
>> including new comments on the spec and existing code proposal.
>> You can find the logs of the conversation here [1].
>>
>> There are 3 main outcomes of the discussion:
>> 1. We hope to get a commitment on the feature (spec and the code) that the 
>> comments would be addressed and code would be ready by Sept 18th; after 
>> which the RC1 is planned to be cut [2]. Our hope is that the spec is merged 
>> way before and implementation to the very least is ready if not merged. The 
>> comments on the spec and merge proposal are currently implementation details 
>> specific so we were positive on this front.
>> 2. The decision to grant FFE will be on Tuesday Sept 8th after the spec has 
>> newer patch sets with major concerns addressed.
>> 3. We cannot commit to granting a backport to this feature so, we ask the 
>> implementors to consider using the plug-ability and modularity of the 
>> taskflow library. You may consult developers who have already worked on 
>> adopting this library in Glance (Flavio, Sabari and Harsh). Deployers can 
>> then use those scripts and put them back in their Liberty deployments even 
>> if it's not in the standard tarball.
>>
>> Please let me know if you have more questions.
>>
>> [1]
>> http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23opensta
>> ck-glance.2015-09-04.log.html#t2015-09-04T14:29:47
>> [2] https://wiki.openstack.org/wiki/Liberty_Release_Schedule
>>
>> On 9/3/15 1:13 PM, Bhandaru, Malini K wrote:
>>> Thank you Nikhil and Brian!
>>>
>>> -Original Message-
>>> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
>>> Sent: Thursday, September 03, 2015 9:42 AM
>>> To: openstack-dev@lists.openstack.org
>>> Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
>>> proposal
>>>
>>> We agreed to hold off on granting it a FFE until tomorrow.
>>>
>>> There's a sync up meeting on this topic tomorrow, Friday Sept 4th at
>>> 14:30 UTC ( #openstack-glance ). Please be there to voice your opinion and 
>>> cast your vote.
>>>
>>> On 9/3/15 9:15 AM, Brian Rosmaita wrote:
 I added an agenda item for this for today's Glance meeting:
https://etherpad.openstack.org/p/glance-team-meeting-agenda

 I'd prefer to hold my vote until after the meeting.

 cheers,
 brian


 On 9/3/15, 6:14 AM, "Kuvaja, Erno"  wrote:

> Malini, all,
>
> My current opinion is -1 for FFE based on the concerns in the spec 
> and implementation.
>
> I'm more than happy to realign my stand after we have updated spec 
> and a) it's agreed to be the approach as of now and b) we can 
> evaluate how much work the implementation needs to meet with the 
> revisited spec.
>
> If we end up to the unfortunate situation that this functionality 
> does not merge in time for Liberty, I'm confident that this is one 
> of the first things in Mitaka. I really don't think there is too 
> much to go, we just might run out of time.
>
> Thanks for your patience and endless effort to get this done.
>
> Best,
> Erno
>
>> -Original Message-
>> From: Bhandaru, Malini K [mailto:malini.k.bhand...@intel.com]
>> Sent: Thursday, September 03, 2015 10:10 AM
>> To: Flavio Percoco; OpenStack Development Mailing List (not for 
>> usage
>> questions)
>> Subject: Re: [openstack-dev] [Glance] 

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

[Vladimir Kuklin]

Folks

I have a strong +1 for the proposal to decouple master node and slave nodes.
Here are the stregnths of this approach
1) We can always decide which particular node runs which particular set of
manifests. This will allow us to do be able to apply/roll back changes
node-by-node. This is very important from operations perspective.
2) We can decouple master and slave nodes manifests and not drag new
library version onto the master node when it is not needed. This allows us
to decrease probability of regressions
3) This makes life easier for the user - you just run 'apt-get/yum install'
instead of some difficult to digest `mco` command.

The only weakness that I see here is on mentioned by Andrey. I think we can
fix it by providing developers with clean and simple way of building
library package on the fly. This will make developers life easier enough to
work with proposed approach.

Also, we need to provide ways for better UX, like provide one button/api
call for:

1) update all manifests on particular nodes (e.g. all or only a part of
nodes of the cluster) to particular version
2)  revert all manifests back to the version which is provided by the
particular GA release
3) 

So far I would mark need for simple package-building system for developer
as a dependency for the proposed change, but I do not see any other way
than proceeding with it.



On Thu, Sep 10, 2015 at 11:50 AM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:

> Oleg,
>
> Alex gave a perfect example regarding support folks when they need to fix
> something really quick. It's client's choice what to patch or not. You may
> like it or not, but it's client's choice.
>
> On 10 Sep 2015, at 09:33, Oleg Gelbukh  wrote:
>
> Alex,
>
> I absolutely understand the point you are making about need for deployment
> engineers to modify things 'on the fly' in customer environment. It's makes
> things really flexible and lowers the entry barrier for sure.
>
> However, I would like to note that in my opinion this kind on 'monkey
> patching' is actually a bad practice for any environments other than dev
> ones. It immediately leads to emergence of unsupportable frankenclouds. I
> would greet any modification to the workflow that will discourage people
> from doing that.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Wed, Sep 9, 2015 at 5:56 PM, Alex Schultz 
> wrote:
>
>> Hey Vladimir,
>>
>>
>>
>>> Regarding plugins: plugins are welcome to install specific additional
>>> DEB/RPM repos on the master node, or just configure cluster to use
>>> additional onl?ne repos, where all necessary packages (including plugin
>>> specific puppet manifests) are to be available. Current granular deployment
>>> approach makes it easy to append specific pre-deployment tasks
>>> (master/slave does not matter). Correct me if I am wrong.
>>>
>>>
>> Don't get me wrong, I think it would be good to move to a fuel-library
>> distributed via package only.  I'm bringing these points up to indicate
>> that there is many other things that live in the fuel library puppet path
>> than just the fuel-library package.  The plugin example is just one place
>> that we will need to invest in further design and work to move to the
>> package only distribution.  What I don't want is some partially executed
>> work that only works for one type of deployment and creates headaches for
>> the people actually having to use fuel.  The deployment engineers and
>> customers who actually perform these actions should be asked about
>> packaging and their comfort level with this type of requirements.  I don't
>> have a complete understanding of the all the things supported today by the
>> fuel plugin system so it would be nice to get someone who is more familiar
>> to weigh in on this idea. Currently plugins are only rpms (no debs) and I
>> don't think we are building fuel-library debs at this time either.  So
>> without some work on both sides, we cannot move to just packages.
>>
>>
>>> Regarding flexibility: having several versioned directories with puppet
>>> modules on the master node, having several fuel-libraryX.Y packages
>>> installed on the master node makes things "exquisitely convoluted" rather
>>> than flexible. Like I said, it is flexible enough to use mcollective, plain
>>> rsync, etc. if you really need to do things manually. But we have
>>> convenient service (Perestroika) which builds packages in minutes if you
>>> need. Moreover, In the nearest future (by 8.0) Perestroika will be
>>> available as an application independent from CI. So, what is wrong with
>>> building fuel-library package? What if you want to troubleshoot nova (we
>>> install it using packages)? Should we also use rsync for everything else
>>> like nova, mysql, etc.?
>>>
>>>
>> Yes, we do have a service like Perestroika to build packages for us.
>> That doesn't mean everyone else does or has access to do that today.
>> Setting up a build system is a major undertaking and 

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Dmitry Tantsur]

On 09/09/2015 06:48 PM, Jim Rollenhagen wrote:

On Tue, Sep 01, 2015 at 03:47:03PM -0500, Dean Troyer wrote:

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann 
wrote:


Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

On 24/08/15 18:19 +, Tim Bell wrote:



>From a user perspective, where bare metal and VMs are just different

flavors (with varying capabilities), can we not use the same commands
(server create/rebuild/...) ? Containers will create the same conceptual
problems.


OSC can provide a converged interface but if we just replace '$ ironic

' by '$ openstack baremetal ', this seems to be a missed
opportunity to hide the complexity from the end user.


Can we re-use the existing server structures ?




I've wondered about how users would see doing this, we've done it already
with the quota and limits commands (blurring the distinction between
project APIs).  At some level I am sure users really do not care about some
of our project distinctions.



To my knowledge, overriding or enhancing existing commands like that

is not possible.

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.



I do have an experimental plugin that hooks the server create command to
add some options and change its behaviour so it is possible, but right now
I wouldn't call it supported at all.  That might be something that we could
consider doing though for things like this.

The current model for commands calling multiple project APIs is to put them
in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations into
the current verbs as much as possible.  It is best to think in terms of how
the CLI user is thinking and what she wants to do, and not how the REST or
Python API is written.  In this case, 'baremetal' is a type of server, a
set of attributes of a server, etc.  As mentioned earlier, containers will
also have a similar paradigm to consider.


Disclaimer: I don't know much about OSC or its syntax, command
structure, etc. These may not be well-formed thoughts. :)


With the same disclaimer applied...



While it would be *really* cool to support the same command to do things
to nova servers or do things to ironic servers, I don't know that it's
reasonable to do so.

Ironic is an admin-only API, that supports running standalone or behind
a Nova installation with the Nova virt driver. The API is primarily used
by Nova, or by admins for management. In the case of a standalone
configuration, an admin can use the Ironic API to deploy a server,
though the recommended approach is to use Bifrost[0] to simplify that.
In the case of Ironic behind Nova, users are expected to boot baremetal
servers through Nova, as indicated by a flavor.

So, many of the nova commands (openstack server foo) don't make sense in
an Ironic context, and vice versa. It would also be difficult to
determine if the commands should go through Nova or through Ironic.
The path could be something like: check that Ironic exists, see if user
has access, hence standalone mode (oh wait, operators probably have
access to manage Ironic *and* deploy baremetal through Nova, what do?).


I second this. I'd like also to add that in case of Ironic "server 
create" may involve actually several complex actions, that do not map to 
'nova boot'. First of all we create a node record in database, second we 
check it's power credentials, third we do properties inspection, finally 
we do cleaning. None of these make any sense on a virtual environment.




I think we should think of "openstack baremetal foo" as commands to
manage the baremetal service (Ironic), as that is what the API is
primarily intended for. Then "openstack server foo" just does what it
does today, and if the flavor happens to be a baremetal flavor, the user
gets a baremetal server.

// jim

[0] https://github.com/openstack/bifrost

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




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

Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[Lucas Alvares Gomes]

Hi,

> Disclaimer: I don't know much about OSC or its syntax, command
> structure, etc. These may not be well-formed thoughts. :)
>

Same here, I don't know much about OSC in general.

> So, many of the nova commands (openstack server foo) don't make sense in
> an Ironic context, and vice versa. It would also be difficult to
> determine if the commands should go through Nova or through Ironic.
> The path could be something like: check that Ironic exists, see if user
> has access, hence standalone mode (oh wait, operators probably have
> access to manage Ironic *and* deploy baremetal through Nova, what do?).
>

I was looking at the list of OSC commands [1], some I can think it
could be possible to map to Ironic functions are:

* openstack server create
* openstack server delete
* openstack server list
* openstack server show
* openstack server reboot
* openstack server rebuild

But when I go to the specifics, I find it hard to map all the
parameters supported for it in the Ironic context, i.e the "openstack
server list" command [2] supports parameters such as "--flavor" or
"--instance-name" to search by flavor or instance name wouldn't be
possible to be implement in Ironic at present (we don't keep such
information registered within the deployed Nodes); among other things
"--ip", "--ip6", etc...

So I think it may worth to do a better research about those commands
and it's parameters to see what can be reused in the Ironic context.
But, at first glance it also seems to me that this is going to bring
more confusion around the usage of the CLI than actually help by
having generic commands for different services.

[1] 
http://docs.openstack.org/cli-reference/content/openstackclient_commands.html
[2] 
http://docs.openstack.org/cli-reference/content/openstackclient_commands.html#openstackclient_subcommand_server_list

Cheers,
Lucas

__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Igor

Having poor access to the internet is a regular use case which we must
support. This is not a crazy requirement. Not having full ISO makes cloud
setup harder to complete. Even more, not having hard requirement to create
a mirror will detract newcomers. I can say that if I were a user and saw a
requirement to create mirror I would not try the product with comparison to
the case when I can get a full ISO with all the stuff I need.

On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Guys,
>
> I really appreciate your opinions on whether Fuel should be all inclusive
> or not. But the original topic of this thread is different. I personally
> think that in 2015 it is not a big deal to make the master node able to
> access any online host (even taking into account paranoid security
> policies). It is just a matter of network engineering. But it is completely
> out of the scope. What I am suggesting is to align the way how we treat
> different repos, whether upstream or MOS. What I am working on right now is
> I am trying to make Fuel build and delivery approach really flexible. That
> means we need to have as little non-standard ways/hacks/approaches/options
> as possible.
>
> > Why can't we make this optional in the build system? It should be easy
> to implement, is not it?
>
> That is exactly what I am trying to do (make it optional). But I don't
> want it to be yet another boolean variable for this particular thing (MOS
> repo). We have working approach for dealing with repos. Repos can either
> online or local mirrors. We have a tool for making local mirrors
> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
> deploy OpenStack, because he/she still needs upstream to be available.
> Anyway, the user is still forced to do some additional actions. Again, we
> have plans to improve the quality and UX of fuel-createmirror.
>
> Yet another thing I don't want to be on the master node is a bunch of MOS
> repos directories named like
> /var/www/nailgun/2015.1-7.0
> /var/www/nailgun/2014.4-6.1
> with links like
> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
> What does this link mean? Even Fuel developers can be confused. It is
> scary to imagine what users think of it :-) Why should Nailgun and upgrade
> script manage that kind of storage in this exact kind of format? A long
> time ago people invented RPM/DEB repositories, tools to manage them and
> structure for versioning them. We have Perestoika for that and we have
> plans to put all package/mirror related tools in one place (
> github.com/stackforge/fuel-mirror) and make all these tools available out
> of Fuel CI. So, users will be able to easily build their own packages,
> clone necessary repos and manage them in the way which is standard in the
> industry. However, it is out of the scope of the letter.
>
> I also don't like the idea of putting MOS repo on the ISO by default
> because it encourages people thing that ISO is the way of distributing MOS.
> ISO should be nothing more than just a way of installing Fuel from scratch.
> MOS should be distributed via MOS repos. Fuel is available as RPM package
> in RPM MOS repo.
>
>
>
>
>
>
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
> wrote:
>
>> Mike,
>>
>> > still not exactly true for some large enterprises. Due to all the
>> security, etc.,
>> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>>
>> It's their problem, and their policies. We can't and shouldn't handle
>> all possible cases. If some enterprise has "no Internet" policy, I bet
>> it won't be a problem for their IT guys to create an intranet mirror
>> for MOS packages. Moreover, I also bet they do have a mirror for
>> Ubuntu or other Linux distributive. So it basically about approach how
>> to consume our mirrors.
>>
>> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
>> wrote:
>> > Folks
>> >
>> > I think, Mike is completely right here - we need an option to build
>> > all-in-one ISO which can be tried-out/deployed unattendedly without
>> internet
>> > access. Let's let a user make a choice what he wants, not push him into
>> > embarassing situation. We still have many parts of Fuel which make
>> choices
>> > for user that cannot be overriden. Let's not pretend that we know more
>> than
>> > user does about his environment.
>> >
>> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
>> > wrote:
>> >>
>> >> The reason people want offline deployment feature is not because of
>> poor
>> >> connection, but rather the enterprise intranets where getting subnet
>> with
>> >> external access sometimes is a real pain in various body parts.
>> >>
>> >> --
>> >> Best regards,
>> >> Oleg Gelbukh
>> >>
>> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I agree with Vladimir - the 

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

[Timur Sufiev]

I went forward and filed a bug for this issue (since we agreed that it
should be fixed): https://bugs.launchpad.net/horizon/+bug/1494251
The code is already in gerrit (see links in bug), feel free to review.

On Fri, Jul 10, 2015 at 1:51 AM Douglas Fish  wrote:

> I think another important question is how to represent this to the user on
> the login screen. "Keystone Endpoint:" matches the setting, but seems like
> a weird choice to me. Is there a better terminology to use for the label
> for this on the login screen?
>
> I see the related selector has no label at all in the header. Maybe using
> the same label there would be a good idea.
>
> Doug
>
> Thai Q Tran/Silicon Valley/IBM@IBMUS wrote on 07/08/2015 01:05:53 PM:
>
> > From: Thai Q Tran/Silicon Valley/IBM@IBMUS
> > To: "OpenStack Development Mailing List \(not for usage questions\)"
> > 
> > Date: 07/09/2015 01:17 PM
> > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> > of 'region' entity: finding better names for them
> >
> > Had the same issue when I worked on the context selection menu for
> > switching domain and project. I think it make sense to rename it to
> > AVAILABLE_KEYSTONE_ENDPOINTS. Since it is local_settings.py, its
> > going to affect some folks (maybe even break) until they also update
> > their setting, something that would have to be done manually.
> >
> > -Jay Pipes  wrote: -
> > To: openstack-dev@lists.openstack.org
> > From: Jay Pipes 
> > Date: 07/08/2015 07:14AM
> > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds
> > of 'region' entity: finding better names for them
>
> > Got it, thanks for the excellent explanation, Timur! Yeah, I think
> > renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution.
> >
> > Best,
> > -jay
> >
> > On 07/08/2015 09:53 AM, Timur Sufiev wrote:
> > > Hi, Jay!
> > >
> > > As Doug said, Horizon regions are just different Keystone endpoints
> that
> > > Horizon could use to authorize against (and retrieve the whole catalog
> > > from any of them afterwards).
> > >
> > > Another example of how complicated things could be: imagine that
> Horizon
> > > config has two Keystone endpoints inside AVAILABLE_REGIONS setting,
> > > http://keystone.europe and http://keystone.asia, each of them hosting
> a
> > > different catalog with service endpoint pointing to Europe/Asia located
> > > services. For European Keystone all Europe-based services are marked as
> > > 'RegionOne', for Asian Keystone all its Asia-based services are marked
> > > as 'RegionOne'. Then, imagine that each Keystone also has 'RegionTwo'
> > > region, for European Keystone the Asian services are marked so, for
> > > Asian Keystone the opposite is true. One of customers did roughly the
> > > same thing (with both Keystones using common LDAP backend), and
> > > understanding what exactly in Horizon didn't work well was a puzzling
> > > experience.
> > >
> > > On Wed, Jul 8, 2015 at 4:37 PM Jay Pipes  > > > wrote:
> > >
> > > On 07/08/2015 08:50 AM, Timur Sufiev wrote:
> > >  > Hello, folks!
> > >  >
> > >  > Somehow it happened that we have 2 different kinds of regions:
> the
> > >  > service regions inside Keystone catalog and AVAILABLE_REGIONS
> setting
> > >  > inside Horizon, yet use the same name 'regions' for both of
> them.
> > > That
> > >  > creates a lot of confusion when solving some
> region-relatedissues at
> > >  > the Horizon/Keystone junction, even explaining what is exactly
> being
> > >  > broken poses a serious challenge when our common language has
> > > such a flaw!
> > >  >
> > >  > I propose to invent 2 distinct terms for these entities, so at
> > > least we
> > >  > won't be terminologically challenged when fixing the related
> bugs.
> > >
> > > Hi!
> > >
> > > I understand what the Keystone region represents: a simple,
> > > non-geographically-connotated division of the entire OpenStack
> > > deployment.
> > >
> > > Unfortunately, I don't know what the Horizon regions represent.
> Could
> > > you explain?
> > >
> > > Best,
> > > -jay
> > >
> > >
> >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >
> 
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > 

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

[Thierry Carrez]

Sean Dague wrote:
> Right now, they are all a bunch of files, they can be anywhere. And then
> you have other files that have to reference these files by path, which
> can be anywhere. We could just punt in that part and say "punt! every
> installer and configuration management install needs to solve this on
> their own." I'm not convinced that's a good answer. The os-brick filters
> aren't really config. If you change them all that happens is
> terribleness. Stuff stops working, and you don't know why. They are data
> to exchange with another process about how to function. Honestly, they
> should probably be python code that's imported by rootwrap.
> 
> Much like the issues around clouds failing when you try to GET /v2 on
> the Nova API (because we have a bunch of knobs you have to align for SSL
> termination, and a bunch of deployers didn't), I don't think we should
> be satisfied with "there's a config for that!" when all that config
> means is that someone can break their configuration if they don't get it
> exactly right.

My quick 2cents on this. Rootwrap was designed as a generic solution to
wrap privileged calls. That's why filter files are part of its
"configuration". The problem is, OpenStack needs a pretty precise set of
those filters to be "configured" to run properly. So it's configuration
for rootwrap, but not "configuration" for OpenStack.

The way it was supposed to work out was that you would have a single
rootwrap on nodes and every component on that node needing filters would
drop them in some unique location. A library is just another component
needing filters, so os-brick could just deploy a few more filters on
nodes where it's installed.

The trick is, to increase "security" we promoted usage of per-project
directories (so that Nova only has access to Nova privileged commands),
which translated into using a specific config file for Nova rootwrap
pointing to Nova filters. Now if we are willing to sacrifice that, we
could have a single directory per-node (/usr/share/rootwrap instead of
/usr/share/*/rootwrap) that makes most of the interpolation you're
describing unnecessary.

Alternatively you could keep project-specific directories and have
os-brick drop symbolic links to its filters into both nova and
cinder-specific directories. It's slightly less flexible (since the lib
now has to know what consumes it) but keeps you from sacrificing "security".

Now another problem you're describing is that there is no single place
where those filters end up, depending on the way the projects (or libs)
are packaged and installed. And it's up to the distros to "fix" the
filters_path in the configuration file so that it points to every single
place where those end up. It's a problem (especially when you start to
install things using multiple concurrent packaging systems), but it's
not exactly new -- it's just that libraries shipping fliters file are
even more likely to ship their filters somewhere weird. So maybe we can
continue to live with that problem we always had, until the privsep
system completely replaces rootwrap ?

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

[Sean Dague]

On 09/10/2015 08:23 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> Right now, they are all a bunch of files, they can be anywhere. And then
>> you have other files that have to reference these files by path, which
>> can be anywhere. We could just punt in that part and say "punt! every
>> installer and configuration management install needs to solve this on
>> their own." I'm not convinced that's a good answer. The os-brick filters
>> aren't really config. If you change them all that happens is
>> terribleness. Stuff stops working, and you don't know why. They are data
>> to exchange with another process about how to function. Honestly, they
>> should probably be python code that's imported by rootwrap.
>>
>> Much like the issues around clouds failing when you try to GET /v2 on
>> the Nova API (because we have a bunch of knobs you have to align for SSL
>> termination, and a bunch of deployers didn't), I don't think we should
>> be satisfied with "there's a config for that!" when all that config
>> means is that someone can break their configuration if they don't get it
>> exactly right.
> 
> My quick 2cents on this. Rootwrap was designed as a generic solution to
> wrap privileged calls. That's why filter files are part of its
> "configuration". The problem is, OpenStack needs a pretty precise set of
> those filters to be "configured" to run properly. So it's configuration
> for rootwrap, but not "configuration" for OpenStack.
> 
> The way it was supposed to work out was that you would have a single
> rootwrap on nodes and every component on that node needing filters would
> drop them in some unique location. A library is just another component
> needing filters, so os-brick could just deploy a few more filters on
> nodes where it's installed.
> 
> The trick is, to increase "security" we promoted usage of per-project
> directories (so that Nova only has access to Nova privileged commands),
> which translated into using a specific config file for Nova rootwrap
> pointing to Nova filters. Now if we are willing to sacrifice that, we
> could have a single directory per-node (/usr/share/rootwrap instead of
> /usr/share/*/rootwrap) that makes most of the interpolation you're
> describing unnecessary.
> 
> Alternatively you could keep project-specific directories and have
> os-brick drop symbolic links to its filters into both nova and
> cinder-specific directories. It's slightly less flexible (since the lib
> now has to know what consumes it) but keeps you from sacrificing "security".
> 
> Now another problem you're describing is that there is no single place
> where those filters end up, depending on the way the projects (or libs)
> are packaged and installed. And it's up to the distros to "fix" the
> filters_path in the configuration file so that it points to every single
> place where those end up. It's a problem (especially when you start to
> install things using multiple concurrent packaging systems), but it's
> not exactly new -- it's just that libraries shipping fliters file are
> even more likely to ship their filters somewhere weird. So maybe we can
> continue to live with that problem we always had, until the privsep
> system completely replaces rootwrap ?

I do get this is where we came from. I feel like this doesn't really
address or understand that things are actually quite different when it
comes to libraries doing rootwrap. We've spent weeks attempting various
work arounds, and for Liberty just punted and said "os-brick, cinder,
and nova all must upgrade exactly at the same time". Because that's the
only solution that doesn't require pages of documentation that
installers will get wrong some times.

I don't feel like that's an acceptable solution. And it also means that
"living" with it means that next cycle we're going to have to say "nova,
neutron, cinder, os-brick, and vif library must all upgrade at exactly
the same time". Which is clearly not a thing we want. Had we figured out
this rootwrap limitation early, os-brick would never have been put into
Nova because it makes the upgrade process demonstrably worse and more
fragile.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

[Asselin, Ramy]

I added Fnst OpenStackTest 
CI
 to the third-party ci group.
Ramy

From: Evgeny Antyshev [mailto:eantys...@virtuozzo.com]
Sent: Thursday, September 10, 2015 3:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit 
server


On 10.09.2015 11:30, Xie, Xianshan wrote:
Hi, all,
   In my CI environment, after submitting a patch into openstack-dev/sandbox,
the Jenkins Job can be launched automatically, and the result message of the 
job also can be posted into the gerrit server successfully.
Everything seems fine.

But in the "Verified" column, there is no verified vote, such as +1 or -1.
You will be able when your CI account is added to "Third-Party CI" group on 
review.openstack.org
https://review.openstack.org/#/admin/groups/270,members
I advice you to ask for such a permission in an IRC meeting for third-party CI 
maintainers:
https://wiki.openstack.org/wiki/Meetings/ThirdParty
But you still won't be able to vote on other projects, except the sandbox.


(patch url: https://review.openstack.org/#/c/222049/,
CI name:  Fnst OpenStackTest CI)

Although I have already added the "verified" label into the layout.yaml , under 
the check pipeline, it does not work yet.

And my configuration info is setted as follows:
Layout.yaml
---
pipelines:
  - name: check
   trigger:
 gerrit:
  - event: patchset-created
  - event: change-restored
  - event: comment-added
...
   success:
gerrit:
  verified: 1
   failure:
gerrit:
  verified: -1

jobs:
   - name: noop-check-communication
  parameter-function: reusable_node
projects:
- name: openstack-dev/sandbox
   - noop-check-communication
---


And the projects.yaml of Jenkins job:
---
- project:
name: sandbox
jobs:
  - noop-check-communication:
 node: 'devstack_slave || devstack-precise-check || d-p-c'
...
---

Could anyone help me? Thanks in advance.

Xiexs





__

OpenStack Development Mailing 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] Fwd: Re: [neutron][L3][dvr][fwaas] FWaaS

[bharath]

Hi ,

neutron-openvswitch-agent is crashing with below error

2015-09-10 04:39:36.675 DEBUG neutron.agent.linux.utils 
[req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None]
Command: ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', 
'--', '--columns=name,other_config,tag', 'list', 'Port', u'tap8e259da4-e8']

Exit code: 0
 from (pid=26026) execute 
/opt/stack/neutron/neutron/agent/linux/utils.py:157
*2015-09-10 04:39:36.675 ERROR 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None] invalid literal for 
int() with base 10: 'None' Agent terminated!**
**2015-09-10 04:39:36.677 INFO oslo_rootwrap.client 
[req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None] Stopping rootwrap 
daemon process with pid=26080**

*
I suspect commit "*Implement external physical bridge mapping in 
linuxbridge*" causing the breakage. [*commit-id: 
bd734811753a99d61e30998c734e465a8d507b8f*]


When i set the branch back to b6d780a83cd9a811e8a91db77eb24bb65fa0b075 
commit , issue is not seen.


I am raising a defect for this.

Thanks,
bharath





On Thursday 10 September 2015 02:52 PM, bharath wrote:

Hi ,

Instance creation is failing with below error from last 4 days.

*2015-09-10 02:14:00.583 WARNING 
neutron.plugins.ml2.drivers.mech_agent 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Attempting to bind with dead agent: 
{'binary': u'neutron-openvswitch-agent', 'des
cription': None, 'admin_state_up': True, 'heartbeat_timestamp': 
datetime.datetime(2015, 9, 10, 9, 6, 57), 'alive': False, 'topic': 
u'N/A', 'host': u'ci-jslave-base', 'agent_type': u'Open vSwitch 
agent', 'created_at': datetime.datetime(2
015, 9, 10, 9, 4, 57), 'started_at': datetime.datetime(2015, 9, 10, 9, 
6, 57), 'id': u'aa9098fe-c412-449e-b979-1f5ab46c3c1d', 
'configurations': {u'in_distributed_mode': False, 
u'arp_responder_enabled': False, u'tunneling_ip': u'192.168.
30.41', u'devices': 0, u'log_agent_heartbeats': False, 
u'l2_population': False, u'tunnel_types': [u'vxlan'], 
u'enable_distributed_routing': False, u'bridge_mappings': {u'ext': 
u'br-ext', u'mng': u'br-mng'}}}*
2015-09-10 02:14:00.583 DEBUG neutron.plugins.ml2.drivers.mech_agent 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Attempting to bind port 
6733610d-e7dc-4ecd-a810-b2b791af9b97 on network c6fb26cc-96
1e-4f38-bf40-bfc72cc59f67 from (pid=25516) bind_port 
/opt/stack/neutron/neutron/plugins/ml2/drivers/mech_agent.py:60
*2015-09-10 02:14:00.588 ERROR neutron.plugins.ml2.managers 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Failed to bind port 
6733610d-e7dc-4ecd-a810-b2b791af9b97 on host ci-jslave-base
2015-09-10 02:14:00.588 ERROR neutron.plugins.ml2.managers 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Failed to bind port 
6733610d-e7dc-4ecd-a810-b2b791af9b97 on host ci-jslave-base*
2015-09-10 02:14:00.608 DEBUG neutron.plugins.ml2.db 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] For port 
6733610d-e7dc-4ecd-a810-b2b791af9b97, host ci-jslave-base, cleared 
binding levels from (pi
d=25516) clear_binding_levels 
/opt/stack/neutron/neutron/plugins/ml2/db.py:189
2015-09-10 02:14:00.608 DEBUG neutron.plugins.ml2.db 
[req-44530c97-56fa-4d5d-ad35-c5e988ab4644 neutron 
24109c82ae76465c8fb20562cce67a4f] Attempted to set empty binding 
levels from (pid=25516) set_binding_levels /opt/stack/neutron/neutro

n/plugins/ml2/db.py:164


Recent commit seems to be broken this.


During stacking i am getting below error , but i dont know whether its 
related to above issue or not

2015-09-09 15:18:48.658 | ERROR: openstack 'module' object has no attribute 
'UpdateDataSource'

would love some help on this issue

Thanks,
bharath


__
OpenStack Development Mailing 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] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Vladimir Kozhukalov]

> Vladimir's proposal was to use smth similar to MiniCD

Just to clarify. My proposal is to remove DEB MOS repo from the master node
by default and thus from the ISO. That is it.
My proposal does not assume having internet connection during installing
the master node. Fuel RPM packages together with their dependencies are
still there on ISO, thus the master node can be installed w/o internet
connection. Cloud/OpenStack can not be deployed out of the box anyway. It
is because we don't put Ubuntu upstream on ISO. Anyway a user is forced to
make Ubuntu upstream mirror available on the master node (cloning it
locally or via internet connection).

IMO, Fuel in this case is like a browser or bittorrent client. Packages are
available on Linux DVDs but it makes little sense to use them w/o internet
connection.


Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday  wrote:

> Hello, thread!
>
> First let me address some of the very good points Alex raised in his email.
>
> On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz 
> wrote:
>
>> Fair enough, I just wanted to raise the UX issues around these types of
>> things as they should go into the decision making process.
>>
>
> UX issues is what we definitely should address even for ourselves: number
> of things that need to happen to deploy Master with just one small change
> is enormous.
>
>
>> Let me explain why I think having local MOS mirror by default is bad:
>>> 1) I don't see any reason why we should treat MOS  repo other way than
>>> all other online repos. A user sees on the settings tab the list of repos
>>> one of which is local by default while others are online. It can make user
>>> a little bit confused, can't it? A user can be also confused by the fact,
>>> that some of the repos can be cloned locally by fuel-createmirror while
>>> others can't. That is not straightforward, NOT fuel-createmirror UX.
>>>
>>
>> I agree. The process should be the same and it should be just another
>> repo. It doesn't mean we can't include a version on an ISO as part of a
>> release.  Would it be better to provide the mirror on the ISO but not have
>> it enabled by default for a release so that we can gather user feedback on
>> this? This would include improved documentation and possibly allowing a
>> user to choose their preference so we can collect metrics?
>>
>
> I think instead of relying on average user of spherical Fuel we should let
> user decide what goes to ISO.
>
> 2) Having local MOS mirror by default makes things much more convoluted.
>>> We are forced to have several directories with predefined names and we are
>>> forced to manage these directories in nailgun, in upgrade script, etc. Why?
>>> 3) When putting MOS mirror on ISO, we make people think that ISO is
>>> equal to MOS, which is not true. It is possible to implement really
>>> flexible delivery scheme, but we need to think of these things as they are
>>> independent.
>>>
>>
>> I'm not sure what you mean by this. Including a point in time copy on an
>> ISO as a release is a common method of distributing software. Is this a
>> messaging thing that needs to be addressed? Perhaps I'm not familiar with
>> people referring to the ISO as being MOS.
>>
>
> It is so common that some people think it's very broken. But we can fix
> that.
>
> For large users it is easy to build custom ISO and put there what they
>>> need but first we need to have simple working scheme clear for everyone. I
>>> think dealing with all repos the same way is what is gonna makes things
>>> simpler.
>>>
>>
>> Who is going to build a custom ISO? How does one request that? What
>> resources are consumed by custom ISO creation process/request? Does this
>> scale?
>>
>
> How about user building ISO on one's workstation?
>
> This thread is not about internet connectivity, it is about aligning
>>> things.
>>>
>>
>> You are correct in that this thread is not explicitly about internet
>> connectivity, but they are related. Any changes to remove a local
>> repository and only provide an internet based solution makes internet
>> connectivity something that needs to be included in the discussion.  I just
>> want to make sure that we properly evaluate this decision based on end user
>> feedback not because we don't want to manage this from a developer
>> standpoint.
>>
>
> We can use Internet connectivity not only in target DC.
>
> Now what do I mean by all that? Let's make Fuel distribution that's easier
> to develop and distribute while making it more comfortable to use in the
> process.
>
> As Alex pointed out, the common way to distribute an OS is to put some
> number of packages from some snapshot of golden repo on ISO and let user
> install that. Let's say, it's a DVD way (although there was time OS could
> fit CD). The other less common way of distributing OS is a small minimal
> ISO and use online repo to install everything. Let's say, it's a MiniCD way.
>
> Fuel is now using a DVD way: 

Re: [openstack-dev] [kilo-devstack] [disk-usage]

[Sean Dague]

disk = 0 does not mean there is no disk. It means the disk image won't
be expanded to a larger size. The disk used will be whatever your image
size is.

-Sean

On 09/10/2015 06:54 AM, Abhishek Talwar wrote:
> Hi Folks,
> 
> 
> I have installed devstack kilo version of OpenStack and created an
> instance on it with flavor *“m1.nano”* that gives a disk of 0 to your
> instance.
> 
> But while checking disk usage of the instance using *“disk.usage”* meter
> it gives the output to be greater than 0 so how is it possible ?
> 
> 
> *stack@abhishek:/opt/stack/ceilometer$ nova show
> e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa *
> 
> +--++
> 
> 
> | Property | Value |
> 
> +--++
> 
> 
> | OS-DCF:diskConfig | AUTO |
> 
> | OS-EXT-AZ:availability_zone | nova |
> 
> | OS-EXT-SRV-ATTR:host | tcs-HP-Compaq-Elite-8300-SFF |
> 
> | OS-EXT-SRV-ATTR:hypervisor_hostname | tcs-HP-Compaq-Elite-8300-SFF |
> 
> | OS-EXT-SRV-ATTR:instance_name | instance-0002 |
> 
> | OS-EXT-STS:power_state | 1 |
> 
> | OS-EXT-STS:task_state | - |
> 
> | OS-EXT-STS:vm_state | active |
> 
> | OS-SRV-USG:launched_at | 2015-09-10T05:24:19.00 |
> 
> | OS-SRV-USG:terminated_at | - |
> 
> | accessIPv4 | |
> 
> | accessIPv6 | |
> 
> | config_drive | True |
> 
> | created | 2015-09-10T05:24:10Z |
> 
> | flavor | m1.nano (42) |
> 
> | hostId | 4a3e03e0a89fbf3790a1b1cd59b1b10acbaad6aa31a4361996d52440 |
> 
> | id | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa |
> 
> | image | cirros-0.3.2-x86_64-uec (221c46b3-9619-485e-8f60-0e1a363fc0e5) |
> 
> | key_name | - |
> 
> | metadata | {} |
> 
> | name | vmssasa |
> 
> | os-extended-volumes:volumes_attached | [] |
> 
> | progress | 0 |
> 
> | public network | 172.24.4.4 |
> 
> | security_groups | default |
> 
> | status | ACTIVE |
> 
> | tenant_id | 5f4f5ee531a441d7bb3830529e611c7d |
> 
> | updated | 2015-09-10T05:24:19Z |
> 
> | user_id | d04b218204414a1891646735befd449c |
> 
> +--++
> 
> 
> 
> 
> 
> *stack@abhishek:/opt/stack/ceilometer$ nova flavor-show m1.nano *
> 
> ++-+
> 
> | Property | Value |
> 
> ++-+
> 
> | OS-FLV-DISABLED:disabled | False |
> 
> | OS-FLV-EXT-DATA:ephemeral | 0 |
> 
> | disk | 0 |
> 
> | extra_specs | {} |
> 
> | id | 42 |
> 
> | name | m1.nano |
> 
> | os-flavor-access:is_public | True |
> 
> | ram | 64 |
> 
> | rxtx_factor | 1.0 |
> 
> | swap | |
> 
> | vcpus | 1 |
> 
> ++-+
> 
> 
> *stack@abhishek:/opt/stack/ceilometer$ ceilometer sample-list -m
> 'cpu_util' -q "resource_id=e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa"*
> 
> +--++---++--+-+
> 
> 
> | Resource ID | Name | Type | Volume | Unit | Timestamp |
> 
> +--++---++--+-+
> 
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T10:30:54 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T10:20:54 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T10:10:54 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T10:00:54 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T09:48:25 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T09:38:25 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T09:21:42 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T09:11:42 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T09:01:42 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T08:51:42 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T08:41:42 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T08:31:42 |
> 
> | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa | disk.usage | gauge | 2448.0
> | B | 2015-09-10T08:21:42 |
> 
> 
> 
> +--++---++--+-+
> 
> 
> 
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> 

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

[Sean Dague]

On 09/09/2015 07:16 PM, Doug Hellmann wrote:
> Excerpts from Matt Riedemann's message of 2015-09-09 13:45:29 -0500:
>>
>> On 9/9/2015 1:04 PM, Doug Hellmann wrote:
>>> Excerpts from Sean Dague's message of 2015-09-09 13:36:37 -0400:

>> The problem with the static file paths in rootwrap.conf is that we don't 
>> know where those other library filter files are going to end up on the 
>> system when the library is installed.  We could hard-code nova's 
>> rootwrap.conf filter_path to include "/etc/os-brick/rootwrap.d" but then 
> 
> I thought the configuration file passed to rootwrap was something the
> deployer could change, which would let them fix the paths on their
> system. Did I misunderstand what the argument was?
> 
>> that means the deploy/config management tooling that installing this 
>> stuff needs to copy that directory structure from the os-brick install 
>> location (which we're finding non-deterministic, at least when using 
>> data_files with pbr) to the target location that rootwrap.conf cares about.
>>
>> That's why we were proposing adding things to rootwrap.conf that 
>> oslo.rootwrap can parse and process dynamically using the resource 
>> access stuff in pkg_resources, so we just say 'I want you to load the 
>> os-brick.filters file from the os-brick project, thanks.'.
>>
> 
> Doesn't that put the rootwrap config file for os-brick in a place the
> deployer can't change it? Maybe they're not supposed to? If they're not,
> then I agree that burying the actual file inside the library and using
> something like pkgtools to get its contents makes more sense.

Right now, they are all a bunch of files, they can be anywhere. And then
you have other files that have to reference these files by path, which
can be anywhere. We could just punt in that part and say "punt! every
installer and configuration management install needs to solve this on
their own." I'm not convinced that's a good answer. The os-brick filters
aren't really config. If you change them all that happens is
terribleness. Stuff stops working, and you don't know why. They are data
to exchange with another process about how to function. Honestly, they
should probably be python code that's imported by rootwrap.

Much like the issues around clouds failing when you try to GET /v2 on
the Nova API (because we have a bunch of knobs you have to align for SSL
termination, and a bunch of deployers didn't), I don't think we should
be satisfied with "there's a config for that!" when all that config
means is that someone can break their configuration if they don't get it
exactly right.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

[Xie, Xianshan]

Hi Ramy & Evgeny,

Yes, it does work.
Thanks a lot.

Once I thought there is no need to add the CI group for the sandbox project.


Xiexs

From: Asselin, Ramy [mailto:ramy.asse...@hp.com]
Sent: Thursday, September 10, 2015 7:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit 
server

I added Fnst OpenStackTest 
CI
 to the third-party ci group.
Ramy

From: Evgeny Antyshev [mailto:eantys...@virtuozzo.com]
Sent: Thursday, September 10, 2015 3:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit 
server


On 10.09.2015 11:30, Xie, Xianshan wrote:
Hi, all,
   In my CI environment, after submitting a patch into openstack-dev/sandbox,
the Jenkins Job can be launched automatically, and the result message of the 
job also can be posted into the gerrit server successfully.
Everything seems fine.

But in the “Verified” column, there is no verified vote, such as +1 or -1.
You will be able when your CI account is added to "Third-Party CI" group on 
review.openstack.org
https://review.openstack.org/#/admin/groups/270,members
I advice you to ask for such a permission in an IRC meeting for third-party CI 
maintainers:
https://wiki.openstack.org/wiki/Meetings/ThirdParty
But you still won't be able to vote on other projects, except the sandbox.

(patch url: https://review.openstack.org/#/c/222049/,
CI name:  Fnst OpenStackTest CI)

Although I have already added the “verified” label into the layout.yaml , under 
the check pipeline, it does not work yet.

And my configuration info is setted as follows:
Layout.yaml
---
pipelines:
  - name: check
   trigger:
 gerrit:
  - event: patchset-created
  - event: change-restored
  - event: comment-added
…
   success:
gerrit:
  verified: 1
   failure:
gerrit:
  verified: -1

jobs:
   - name: noop-check-communication
  parameter-function: reusable_node
projects:
- name: openstack-dev/sandbox
   - noop-check-communication
---


And the projects.yaml of Jenkins job:
---
- project:
name: sandbox
jobs:
  - noop-check-communication:
 node: 'devstack_slave || devstack-precise-check || d-p-c'
…
---

Could anyone help me? Thanks in advance.

Xiexs




__

OpenStack Development Mailing 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] [tempest] Is there a sandbox project how to use tempest test plugin interface?

[Lajos Katona]

Hi,

I just noticed that from tag 6, the test plugin interface considered 
ready, and I am eager to start to use it.

I have some questions:

If I understand well in the future the plugin interface will be moved to 
tempest-lib, but now I have to import module(s) from tempest to start to 
use the interface.
Is there a plan for this, I mean when the whole interface will be moved 
to tempest-lib?


If I start to create a test plugin now (from tag 6), what should be the 
best solution to do this?
I thought to create a repo for my plugin and add that as a subrepo to my 
local tempest repo, and than I can easily import stuff from tempest, but 
I can keep my test code separated from other parts of tempest.

Is there a better way of doing this?

If there would be an example plugin somewhere, that would be the most 
preferable maybe.


Thanks in advance for the help.

Regards
Lajos

__
OpenStack Development Mailing 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] [kilo-devstack] [disk-usage]

[Abhishek Talwar]

	
	
	
	Hi Folks,I have installed
devstack kilo version of OpenStack and created an instance on it with
flavor “m1.nano” that gives a disk of 0 to your instance.
But while checking
disk usage of the instance using “disk.usage” meter it
gives the output to be greater than 0 so how is it possible ?


stack@abhishek:/opt/stack/ceilometer$
nova show e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa

+--++

| Property  
  | Value
 |

+--++

| OS-DCF:diskConfig 
  | AUTO 
 |

|
OS-EXT-AZ:availability_zone  | nova  
|

|
OS-EXT-SRV-ATTR:host | tcs-HP-Compaq-Elite-8300-SFF  
|

|
OS-EXT-SRV-ATTR:hypervisor_hostname  | tcs-HP-Compaq-Elite-8300-SFF  
|

|
OS-EXT-SRV-ATTR:instance_name| instance-0002 
|

|
OS-EXT-STS:power_state   | 1 
|

|
OS-EXT-STS:task_state| - 
|

|
OS-EXT-STS:vm_state  | active
|

|
OS-SRV-USG:launched_at   | 2015-09-10T05:24:19.00
|

|
OS-SRV-USG:terminated_at | - 
|

| accessIPv4
  |  
 |

| accessIPv6
  |  
 |

| config_drive  
  | True 
 |

| created   
  | 2015-09-10T05:24:10Z 
 |

| flavor
  | m1.nano (42) 
 |

| hostId
  |
4a3e03e0a89fbf3790a1b1cd59b1b10acbaad6aa31a4361996d52440   |

| id
  | e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa 
 |

| image 
  | cirros-0.3.2-x86_64-uec
(221c46b3-9619-485e-8f60-0e1a363fc0e5) |

| key_name  
  | -
 |

| metadata  
  | {}   
 |

| name  
  | vmssasa  
 |

|
os-extended-volumes:volumes_attached | []
|

| progress  
  | 0
 |

| public network
  | 172.24.4.4   
 |

| security_groups   
  | default  
 |

| status
  | ACTIVE   
 |

| tenant_id 
  | 5f4f5ee531a441d7bb3830529e611c7d 
 |

| updated   
  | 2015-09-10T05:24:19Z 
 |

| user_id   
  | d04b218204414a1891646735befd449c 
 |

+--++






stack@abhishek:/opt/stack/ceilometer$
nova flavor-show m1.nano

++-+

| Property  
| Value   |

++-+

|
OS-FLV-DISABLED:disabled   | False   |

|
OS-FLV-EXT-DATA:ephemeral  | 0   |

| disk  
| 0   |

| extra_specs   
| {}  |

| id
| 42  |

| name  
| m1.nano |

|
os-flavor-access:is_public | True|

| ram   
| 64  |

| rxtx_factor   
| 1.0 |

| swap  
| |

| vcpus 
| 1   |

++-+



stack@abhishek:/opt/stack/ceilometer$
ceilometer sample-list -m 'cpu_util' -q
"resource_id=e3fd6b56-25df-4498-aa9d-8d9af3dfb4fa"
+--++---++--+-+

| Resource ID   
  | Name   | Type  | Volume | Unit |
Timestamp   |

[openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Yuriy Taraday]

Hello, thread!

First let me address some of the very good points Alex raised in his email.

On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz  wrote:

> Fair enough, I just wanted to raise the UX issues around these types of
> things as they should go into the decision making process.
>

UX issues is what we definitely should address even for ourselves: number
of things that need to happen to deploy Master with just one small change
is enormous.


> Let me explain why I think having local MOS mirror by default is bad:
>> 1) I don't see any reason why we should treat MOS  repo other way than
>> all other online repos. A user sees on the settings tab the list of repos
>> one of which is local by default while others are online. It can make user
>> a little bit confused, can't it? A user can be also confused by the fact,
>> that some of the repos can be cloned locally by fuel-createmirror while
>> others can't. That is not straightforward, NOT fuel-createmirror UX.
>>
>
> I agree. The process should be the same and it should be just another
> repo. It doesn't mean we can't include a version on an ISO as part of a
> release.  Would it be better to provide the mirror on the ISO but not have
> it enabled by default for a release so that we can gather user feedback on
> this? This would include improved documentation and possibly allowing a
> user to choose their preference so we can collect metrics?
>

I think instead of relying on average user of spherical Fuel we should let
user decide what goes to ISO.

2) Having local MOS mirror by default makes things much more convoluted. We
>> are forced to have several directories with predefined names and we are
>> forced to manage these directories in nailgun, in upgrade script, etc. Why?
>> 3) When putting MOS mirror on ISO, we make people think that ISO is equal
>> to MOS, which is not true. It is possible to implement really flexible
>> delivery scheme, but we need to think of these things as they are
>> independent.
>>
>
> I'm not sure what you mean by this. Including a point in time copy on an
> ISO as a release is a common method of distributing software. Is this a
> messaging thing that needs to be addressed? Perhaps I'm not familiar with
> people referring to the ISO as being MOS.
>

It is so common that some people think it's very broken. But we can fix
that.

For large users it is easy to build custom ISO and put there what they need
>> but first we need to have simple working scheme clear for everyone. I think
>> dealing with all repos the same way is what is gonna makes things simpler.
>>
>
> Who is going to build a custom ISO? How does one request that? What
> resources are consumed by custom ISO creation process/request? Does this
> scale?
>

How about user building ISO on one's workstation?

This thread is not about internet connectivity, it is about aligning things.
>>
>
> You are correct in that this thread is not explicitly about internet
> connectivity, but they are related. Any changes to remove a local
> repository and only provide an internet based solution makes internet
> connectivity something that needs to be included in the discussion.  I just
> want to make sure that we properly evaluate this decision based on end user
> feedback not because we don't want to manage this from a developer
> standpoint.
>

We can use Internet connectivity not only in target DC.

Now what do I mean by all that? Let's make Fuel distribution that's easier
to develop and distribute while making it more comfortable to use in the
process.

As Alex pointed out, the common way to distribute an OS is to put some
number of packages from some snapshot of golden repo on ISO and let user
install that. Let's say, it's a DVD way (although there was time OS could
fit CD). The other less common way of distributing OS is a small minimal
ISO and use online repo to install everything. Let's say, it's a MiniCD way.

Fuel is now using a DVD way: we put everything user will ever need to an
ISO and give it to user. Vladimir's proposal was to use smth similar to
MiniCD way: put only Fuel on ISO and keep online repo running.

Note that I'll speak of Fuel as an installer people put on MiniCD. It's a
bit bigger, but it deploys clouds, not just separate machines. Packages and
OS then translate to everything needed to deploy OpenStack: packages and
deploy scripts (puppet manifests, could be packaged as well). We could
apply the same logic to distribution of Fuel itself though, but let's not
get into it right now.

Let's compare these ways from distributor (D) and user (U) point of view.

DVD way.
Pros:
- (D) a single piece to deliver to user;
- (D,U) a snapshot of repo put on ISO is easier to cover with QA and so
it's better tested;
- (U) one-time download for everything;
- (U) no need for Internet connectivity when you're installing OS;
- (U) you can store ISO and reuse it any number of times.
Cons:
- (D) you still have to maintain online repo for updates;
- (D,U) it's 

[openstack-dev] [Fuel][Plugins] SDK is updated with the latest information

[Irina Povolotskaya]

Hi to all,

Please be informed that the Fuel Plugin SDK now has a set of useful
instructions that cover the following issues:
- how to create a new project for Fuel Plugins in /openstack namespace [1].
- how to add your plugin to DriverLog [2]
- how to form documentation for your plugin [3].

If you suppose some issues are still missing, please let me know.

Thanks.


[1] https://wiki.openstack.org/wiki/Fuel/Plugins#How_to_create_a_project

[2]
https://wiki.openstack.org/wiki/Fuel/Plugins#Add_your_plugin_to_DriverLog
[3]
https://wiki.openstack.org/wiki/Fuel/Plugins#Creating_documentation_for_Fuel_Plugins
-- 
Best regards,

Irina

*Business Analyst*
__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Igor

This is not the case to tell users if they are stupid are not. We are
working for our users, not vice versa.

On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
wrote:

> Mike,
>
> > still not exactly true for some large enterprises. Due to all the
> security, etc.,
> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>
> It's their problem, and their policies. We can't and shouldn't handle
> all possible cases. If some enterprise has "no Internet" policy, I bet
> it won't be a problem for their IT guys to create an intranet mirror
> for MOS packages. Moreover, I also bet they do have a mirror for
> Ubuntu or other Linux distributive. So it basically about approach how
> to consume our mirrors.
>
> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
> wrote:
> > Folks
> >
> > I think, Mike is completely right here - we need an option to build
> > all-in-one ISO which can be tried-out/deployed unattendedly without
> internet
> > access. Let's let a user make a choice what he wants, not push him into
> > embarassing situation. We still have many parts of Fuel which make
> choices
> > for user that cannot be overriden. Let's not pretend that we know more
> than
> > user does about his environment.
> >
> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
> > wrote:
> >>
> >> The reason people want offline deployment feature is not because of poor
> >> connection, but rather the enterprise intranets where getting subnet
> with
> >> external access sometimes is a real pain in various body parts.
> >>
> >> --
> >> Best regards,
> >> Oleg Gelbukh
> >>
> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I agree with Vladimir - the idea of online repos is a right way to
> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
> >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> >>> distributives - most of them fetch needed packages from the Internet
> >>> during installation, not from CD/DVD. The netboot installers are
> >>> popular, I can't even remember when was the last time I install my
> >>> Debian from the DVD-1 - I use netboot installer for years.
> >>>
> >>> Thanks,
> >>> Igor
> >>>
> >>>
> >>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang 
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz  >
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >> Hey Vladimir,
> >>> >>
> >>> >>>
> >>> >>>
> >>> >
> >>> > 1) There won't be such things in like [1] and [2], thus less
> >>> > complicated flow, less errors, easier to maintain, easier to
> >>> > understand,
> >>> > easier to troubleshoot
> >>> > 2) If one wants to have local mirror, the flow is the same as in
> >>> > case
> >>> > of upstream repos (fuel-createmirror), which is clrear for a user
> >>> > to
> >>> > understand.
> >>> 
> >>> 
> >>>  From the issues I've seen,  fuel-createmirror isn't very straight
> >>>  forward and has some issues making it a bad UX.
> >>> >>>
> >>> >>>
> >>> >>> I'd say the whole approach of having such tool as fuel-createmirror
> >>> >>> is a
> >>> >>> way too naive. Reliable internet connection is totally up to
> network
> >>> >>> engineering rather than deployment. Even using proxy is much better
> >>> >>> that
> >>> >>> creating local mirror. But this discussion is totally out of the
> >>> >>> scope of
> >>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> >>> straightforward (installed as rpm, has just a couple of command
> line
> >>> >>> options). The quality of this script is also out of the scope of
> this
> >>> >>> thread. BTW we have plans to improve it.
> >>> >>
> >>> >>
> >>> >>
> >>> >> Fair enough, I just wanted to raise the UX issues around these types
> >>> >> of
> >>> >> things as they should go into the decision making process.
> >>> >>
> >>> >>
> >>> >>>
> >>> >
> >>> >
> >>> > Many people still associate ISO with MOS, but it is not true when
> >>> > using
> >>> > package based delivery approach.
> >>> >
> >>> > It is easy to define necessary repos during deployment and thus
> it
> >>> > is
> >>> > easy to control what exactly is going to be installed on slave
> >>> > nodes.
> >>> >
> >>> > What do you guys think of it?
> >>> >
> >>> >
> >>> 
> >>>  Reliance on internet connectivity has been an issue since 6.1. For
> >>>  many
> >>>  large users, complete access to the internet is not available or
> not
> >>>  desired.  If we want to continue down this path, we need to
> improve
> >>>  the
> >>>  tools to setup the local mirror and properly document what
> >>>  urls/ports/etc
> >>>  need to be available for the installation of openstack and any
> >>>  mirror
> >>> 

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

[Evgeny Antyshev]

On 10.09.2015 11:30, Xie, Xianshan wrote:


Hi, all,

   In my CI environment, after submitting a patch into 
openstack-dev/sandbox,


the Jenkins Job can be launched automatically, and the result message 
of the job also can be posted into the gerrit server successfully.


Everything seems fine.

But in the “Verified” column, there is no verified vote, such as +1 or -1.

You will be able when your CI account is added to "Third-Party CI" group 
on review.openstack.org

https://review.openstack.org/#/admin/groups/270,members
I advice you to ask for such a permission in an IRC meeting for 
third-party CI maintainers:

https://wiki.openstack.org/wiki/Meetings/ThirdParty
But you still won't be able to vote on other projects, except the sandbox.


(patch url: https://review.openstack.org/#/c/222049/,

CI name:  Fnst OpenStackTest CI)

Although I have already added the “verified” label into the 
layout.yaml , under the check pipeline, it does not work yet.


And my configuration info is setted as follows:

Layout.yaml

---

pipelines:

  - name: check

   trigger:

 gerrit:

  - event: patchset-created

  - event: change-restored

  - event: comment-added

…

   success:

gerrit:

  verified: 1

   failure:

gerrit:

  verified: -1

jobs:

   - name: noop-check-communication

  parameter-function: reusable_node

projects:

- name: openstack-dev/sandbox

   - noop-check-communication

---

And the projects.yaml of Jenkins job:

---

- project:

name: sandbox

jobs:

  - noop-check-communication:

 node: 'devstack_slave || devstack-precise-check || d-p-c'

…

---

Could anyone help me? Thanks in advance.

Xiexs



__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Guys,

I really appreciate your opinions on whether Fuel should be all inclusive
or not. But the original topic of this thread is different. I personally
think that in 2015 it is not a big deal to make the master node able to
access any online host (even taking into account paranoid security
policies). It is just a matter of network engineering. But it is completely
out of the scope. What I am suggesting is to align the way how we treat
different repos, whether upstream or MOS. What I am working on right now is
I am trying to make Fuel build and delivery approach really flexible. That
means we need to have as little non-standard ways/hacks/approaches/options
as possible.

> Why can't we make this optional in the build system? It should be easy to
implement, is not it?

That is exactly what I am trying to do (make it optional). But I don't want
it to be yet another boolean variable for this particular thing (MOS repo).
We have working approach for dealing with repos. Repos can either online or
local mirrors. We have a tool for making local mirrors (fuel-createmirror).
Even if we put MOS on the ISO, a user still can not deploy OpenStack,
because he/she still needs upstream to be available. Anyway, the user is
still forced to do some additional actions. Again, we have plans to improve
the quality and UX of fuel-createmirror.

Yet another thing I don't want to be on the master node is a bunch of MOS
repos directories named like
/var/www/nailgun/2015.1-7.0
/var/www/nailgun/2014.4-6.1
with links like
/var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
What does this link mean? Even Fuel developers can be confused. It is scary
to imagine what users think of it :-) Why should Nailgun and upgrade script
manage that kind of storage in this exact kind of format? A long time ago
people invented RPM/DEB repositories, tools to manage them and structure
for versioning them. We have Perestoika for that and we have plans to put
all package/mirror related tools in one place (
github.com/stackforge/fuel-mirror) and make all these tools available out
of Fuel CI. So, users will be able to easily build their own packages,
clone necessary repos and manage them in the way which is standard in the
industry. However, it is out of the scope of the letter.

I also don't like the idea of putting MOS repo on the ISO by default
because it encourages people thing that ISO is the way of distributing MOS.
ISO should be nothing more than just a way of installing Fuel from scratch.
MOS should be distributed via MOS repos. Fuel is available as RPM package
in RPM MOS repo.







Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
wrote:

> Mike,
>
> > still not exactly true for some large enterprises. Due to all the
> security, etc.,
> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>
> It's their problem, and their policies. We can't and shouldn't handle
> all possible cases. If some enterprise has "no Internet" policy, I bet
> it won't be a problem for their IT guys to create an intranet mirror
> for MOS packages. Moreover, I also bet they do have a mirror for
> Ubuntu or other Linux distributive. So it basically about approach how
> to consume our mirrors.
>
> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
> wrote:
> > Folks
> >
> > I think, Mike is completely right here - we need an option to build
> > all-in-one ISO which can be tried-out/deployed unattendedly without
> internet
> > access. Let's let a user make a choice what he wants, not push him into
> > embarassing situation. We still have many parts of Fuel which make
> choices
> > for user that cannot be overriden. Let's not pretend that we know more
> than
> > user does about his environment.
> >
> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
> > wrote:
> >>
> >> The reason people want offline deployment feature is not because of poor
> >> connection, but rather the enterprise intranets where getting subnet
> with
> >> external access sometimes is a real pain in various body parts.
> >>
> >> --
> >> Best regards,
> >> Oleg Gelbukh
> >>
> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I agree with Vladimir - the idea of online repos is a right way to
> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
> >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> >>> distributives - most of them fetch needed packages from the Internet
> >>> during installation, not from CD/DVD. The netboot installers are
> >>> popular, I can't even remember when was the last time I install my
> >>> Debian from the DVD-1 - I use netboot installer for years.
> >>>
> >>> Thanks,
> >>> Igor
> >>>
> >>>
> >>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang 
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[Jay Dobies]

On 09/10/2015 10:06 AM, James Slagle wrote:

TripleO has added a few new repositories, one of which is
python-tripleoclient[1], the former python-rdomanager-oscplugin.

With the additional repositories, there is an additional review burden
on our core reviewers. There is also the fact that folks who have been
working on the client code for a while when it was only part of RDO
are not TripleO core reviewers.

I think we could help with the additional burden of reviews if we made
two of those people core on python-tripleoclient and tripleo-common
now.

Specifically, the folks I'm proposing are:
Brad P. Crochet 
Dougal Matthews 


+1 to both. I've seen a lot of Dougal's reviews and his Python knowledge 
is excellent.



The options I see are:
- keep just 1 tripleo acl, and add additional folks there, with a good
faith agreement not to +/-2,+A code that is not from the 2 client
repos.


+1 to this. I feel like it encourages cross pollination into other 
tripleo repos (we could use the eyes on THT) without having to jump 
through extra hoops as their involvement with them increases.



- create a new gerrit acl in project-config for just these 2 client
repos, and add folks there as needed. the new acl would also contain
the existing acl for tripleo core reviewers
- neither of the above options - don't add these individuals to any
TripleO core team at this time.

The first is what was more or less done when Tuskar was brought under
the TripleO umbrella to avoid splitting the core teams, and it's the
option I'd prefer.

TripleO cores, please reply here with your vote from the above
options. Or, if you have other ideas, you can share those as well :)

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



__
OpenStack Development Mailing 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] Core reviewers for python-tripleoclient and tripleo-common

[Ben Nemec]

On 09/10/2015 09:06 AM, James Slagle wrote:
> TripleO has added a few new repositories, one of which is
> python-tripleoclient[1], the former python-rdomanager-oscplugin.
> 
> With the additional repositories, there is an additional review burden
> on our core reviewers. There is also the fact that folks who have been
> working on the client code for a while when it was only part of RDO
> are not TripleO core reviewers.
> 
> I think we could help with the additional burden of reviews if we made
> two of those people core on python-tripleoclient and tripleo-common
> now.
> 
> Specifically, the folks I'm proposing are:
> Brad P. Crochet 
> Dougal Matthews  

+1 to both

> 
> The options I see are:
> - keep just 1 tripleo acl, and add additional folks there, with a good
> faith agreement not to +/-2,+A code that is not from the 2 client
> repos.

+1 to this.

Personally I would hope that anyone who is a core has the necessary
judgment to not +2 things they don't understand, regardless of project
(and vice versa; Brad and Dougal obviously understand TripleO from their
work on the client, so if they +2 a simple patch in another project I'm
not inclined to take them to the woodshed :-).  "TripleO" is a broad
enough thing that there are areas where all of the cores are going to be
weaker or stronger.  I'd rather not have to maintain half a dozen
separate ACL's just to enforce something that should be common sense.

> - create a new gerrit acl in project-config for just these 2 client
> repos, and add folks there as needed. the new acl would also contain
> the existing acl for tripleo core reviewers
> - neither of the above options - don't add these individuals to any
> TripleO core team at this time.
> 
> The first is what was more or less done when Tuskar was brought under
> the TripleO umbrella to avoid splitting the core teams, and it's the
> option I'd prefer.
> 
> TripleO cores, please reply here with your vote from the above
> options. Or, if you have other ideas, you can share those as well :)
> 
> [1] https://review.openstack.org/#/c/215186/
> 


__
OpenStack Development Mailing 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] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Yuriy Taraday]

On Thu, Sep 10, 2015 at 4:43 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> > Vladimir's proposal was to use smth similar to MiniCD
>
> Just to clarify. My proposal is to remove DEB MOS repo from the master
> node by default and thus from the ISO. That is it.
> My proposal does not assume having internet connection during installing
> the master node. Fuel RPM packages together with their dependencies are
> still there on ISO, thus the master node can be installed w/o internet
> connection. Cloud/OpenStack can not be deployed out of the box anyway. It
> is because we don't put Ubuntu upstream on ISO. Anyway a user is forced to
> make Ubuntu upstream mirror available on the master node (cloning it
> locally or via internet connection).
>
> IMO, Fuel in this case is like a browser or bittorrent client. Packages
> are available on Linux DVDs but it makes little sense to use them w/o
> internet connection.
>
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday 
> wrote:
>
>> Note that I'll speak of Fuel as an installer people put on MiniCD. It's a
>> bit bigger, but it deploys clouds, not just separate machines. Packages and
>> OS then translate to everything needed to deploy OpenStack: packages and
>> deploy scripts (puppet manifests, could be packaged as well). We could
>> apply the same logic to distribution of Fuel itself though, but let's not
>> get into it right now.
>>
>
As I've mentioned later in the initial mail (see above), I'm not talking
about using this approach to deploy Fuel (although it'd be great if we do).
I'm talking about using it to deploy Fuel and then MOS. We can download
some fixed part of the image that contains everything needed to deploy Fuel
and add all necessary repos and manifests to it, for example.

So to repeat the analogy, Fuel is like deb-installer that is present on any
Debian-based MiniCD and MOS (packages+manifests) is like packages that
present on DVD (and downloaded in MiniCD case). You don't want to dig into
deb-installer, but you might want to install different software from
different sources. Just like you don't want to mess with Fuel itself while
you might want to install customized MOS from local repo (or from resulting
image).
__
OpenStack Development Mailing 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] [gate] broken by pyeclib 1.0.9 release

[Matt Riedemann]

On 9/10/2015 9:44 AM, Sean Dague wrote:

The pyeclib 1.0.9 release has broken the gate because Swift is in the
default grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which
doesn't compile correctly with a pip install).

We're working to pin requirements in kilo/juno right now, but anything
that has a grenade job is going to fail until these land.

-Sean



This is the LP bug we're tracking:

https://bugs.launchpad.net/openstack-gate/+bug/1494347

These are the immediate fixes:

Juno g-r cap: https://review.openstack.org/#/c/21/

Kilo g-r pin: https://review.openstack.org/#/c/18/

Upstream bug reported:

https://bitbucket.org/kmgreen2/pyeclib/issues/76/pyeclib-109-fails-to-install-if-not

--

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-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[James Slagle]

TripleO has added a few new repositories, one of which is
python-tripleoclient[1], the former python-rdomanager-oscplugin.

With the additional repositories, there is an additional review burden
on our core reviewers. There is also the fact that folks who have been
working on the client code for a while when it was only part of RDO
are not TripleO core reviewers.

I think we could help with the additional burden of reviews if we made
two of those people core on python-tripleoclient and tripleo-common
now.

Specifically, the folks I'm proposing are:
Brad P. Crochet 
Dougal Matthews 

The options I see are:
- keep just 1 tripleo acl, and add additional folks there, with a good
faith agreement not to +/-2,+A code that is not from the 2 client
repos.
- create a new gerrit acl in project-config for just these 2 client
repos, and add folks there as needed. the new acl would also contain
the existing acl for tripleo core reviewers
- neither of the above options - don't add these individuals to any
TripleO core team at this time.

The first is what was more or less done when Tuskar was brought under
the TripleO umbrella to avoid splitting the core teams, and it's the
option I'd prefer.

TripleO cores, please reply here with your vote from the above
options. Or, if you have other ideas, you can share those as well :)

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

-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] [tempest] Is there a sandbox project how to use tempest test plugin interface?

[Matthew Treinish]

On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote:
> Hi,
> 
> I just noticed that from tag 6, the test plugin interface considered ready,
> and I am eager to start to use it.
> I have some questions:
> 
> If I understand well in the future the plugin interface will be moved to
> tempest-lib, but now I have to import module(s) from tempest to start to use
> the interface.
> Is there a plan for this, I mean when the whole interface will be moved to
> tempest-lib?

The only thing which will eventually move to tempest-lib is the abstract class
that defines the expected methods of a plugin class [1] The other pieces will
remain in tempest. Honestly this won't likely happen until sometime during
Mitaka. Also when it does move to tempest-lib we'll deprecate the tempest
version and keep it around to allow for a graceful switchover.

The rationale behind this is we really don't provide any stability guarantees
on tempest internals (except for a couple of places which are documented, like
this plugin class) and we want any code from tempest that's useful to external
consumers to really live in tempest-lib.

> 
> If I start to create a test plugin now (from tag 6), what should be the best
> solution to do this?
> I thought to create a repo for my plugin and add that as a subrepo to my
> local tempest repo, and than I can easily import stuff from tempest, but I
> can keep my test code separated from other parts of tempest.
> Is there a better way of doing this?

To start I'd take a look at the documentation for tempest plugins:

http://docs.openstack.org/developer/tempest/plugin.html

From tempest's point of view a plugin is really just an entry point that points
to a class that exposes certain methods. So the Tempest plugin can live anywhere
as long as it's installed as an entry point in the proper namespace. Personally
I feel like including it as a subrepo in a local tempest tree is a bit strange,
but I don't think it'll cause any issues if you do that.

> 
> If there would be an example plugin somewhere, that would be the most
> preferable maybe.

There is a cookiecutter repo in progress. [2] Once that's ready it'll let you
create a blank plugin dir that'll be ready for you to populate. (similar to the
devstack plugin cookiecutter that already exists)

For current examples the only project I know of that's using a plugin interface
is manila [3] so maybe take a look at what they're doing.

-Matt Treinish

[1] 
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/test_discover/plugins.py#n26
[2] https://review.openstack.org/208389
[3] https://review.openstack.org/#/c/201955


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

[openstack-dev] [openstack-ansible] Security hardening

[Major Hayden]

Hey there,

I've been looking for some ways to harden the systems that are deployed by 
os-ansible-deployment (soon to be openstack-ansible?) and I've been using the 
Center for Internet Security (CIS)[1] benchmarks as a potential pathway for 
that.  There are benchmarks available for various operating systems and 
applications there.

Many of the items shown there fall into a few different categories:

  1) things OSAD should configure
  2) things deployers should configure
  3) things nobody should configure (they break the deployment, for example)

#3 is often quite obvious, but #1 and #2 are a bit more nebulous.  For example, 
I opened a ticket[2] about getting auditd installed by default with 
openstack-ansible.  My gut says that many deployers could use auditd since it 
collects denials from AppArmor and that can help with troubleshooting broken 
policies.

Also, I opened another ticket[3] for compressing all logs by default.  This 
affects availability (part of the information security CIA triad[4]) in a 
fairly critical way in the long term.

My question is this: How should I go about determining which security changes 
should go upstream and which should go into documentation as things deployers 
should do locally?


[1] https://benchmarks.cisecurity.org/
[2] https://bugs.launchpad.net/openstack-ansible/+bug/1491915
[3] https://bugs.launchpad.net/openstack-ansible/+bug/1493981
[4] https://en.wikipedia.org/wiki/Information_security#Key_concepts

--
Major Hayden

__
OpenStack Development Mailing 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] [Ansible][Infra] Moving ansible roles into big tent?

[Paul Belanger]

On Thu, Sep 10, 2015 at 09:31:47AM +0200, Yolanda Robla Mota wrote:
> Hi
> I will be interested as well. Having these playbooks in ansible can also be
> useful
> in order to integrate with infra-ansible project.
> I really see that collection as a valid alternative for puppet modules, with
> the advantages
> that ansible can provide, but of course that moving from puppet to ansible
> on infra internally
> is something that cannot be done easily, and needs a wider discussion.
> If we limit the scope of the ansible playbooks only to infra components, I
> think that infra
> namespace is the way to go, having an independent group of reviewers.
> 
Right, I don't want to go down the path of having openstack-infra consume
ansible. I believe puppet will the default for a while to come. So, if both can
live under the openstack-infra namespace, that works for me.

> Best
> Yolanda
> 
> 
> El 09/09/15 a las 21:31, Ricardo Carrillo Cruz escribió:
> >I'm interested in ansible roles for openstack-infra, but as there is
> >overlap in functionality
> >with the current openstack-infra puppet roles I'm not sure what's the
> >stance from the
> >openstack-infra core members and PTL.
> >
> >I think they should go to openstack-infra, since Nodepoo/Zuul/etc are very
> >specific
> >to the OpenStack CI.
> >
> >Question is if we should have a subgroup within openstack-infra namespace
> >for
> >'stuff that is not used by OpenStack CI but interesting from CI
> >perspective and/or
> >used by other downstream groups'.
> >
> >Regards
> >
> >2015-09-09 19:22 GMT+02:00 Paul Belanger  >>:
> >
> >On Tue, Sep 08, 2015 at 06:50:38PM -0400, Emilien Macchi wrote:
> >>
> >>
> >> On 09/08/2015 10:57 AM, Paul Belanger wrote:
> >> > Greetings,
> >> >
> >> > I wanted to start a discussion about the future of ansible /
> >ansible roles in
> >> > OpenStack. Over the last week or so I've started down the
> >ansible path, starting
> >> > my first ansible role; I've started with ansible-role-nodepool[1].
> >> >
> >> > My initial question is simple, now that big tent is upon us, I
> >would like
> >> > some way to include ansible roles into the opentack git
> >workflow.  I first
> >> > thought the role might live under openstack-infra however I am
> >not sure that
> >> > is the right place.  My reason is, -infra tents to include
> >modules they
> >> > currently run under the -infra namespace, and I don't want to
> >start the effort
> >> > to convince people to migrate.
> >>
> >> I'm wondering what would be the goal of ansible-role-nodepool
> >and what
> >> it would orchestrate exactly. I did not find README that
> >explains it,
> >> and digging into the code makes me think you try to prepare nodepool
> >> images but I don't exactly see why.
> >>
> >> Since we already have puppet-nodepool, I'm curious about the
> >purpose of
> >> this role.
> >> IMHO, if we had to add such a new repo, it would be under
> >> openstack-infra namespace, to be consistent with other repos
> >> (puppet-nodepool, etc).
> >>
> >> > Another thought might be to reach out to the
> >os-ansible-deployment team and ask
> >> > how they see roles in OpenStack moving foward (mostly the
> >reason for this
> >> > email).
> >>
> >> os-ansible-deployment aims to setup OpenStack services in containers
> >> (LXC). I don't see relation between os-ansible-deployment (openstack
> >> deployment related) and ansible-role-nodepool (infra related).
> >>
> >> > Either way, I would be interested in feedback on moving
> >forward on this. Using
> >> > travis-ci and github works but OpenStack workflow is much better.
> >> >
> >> > [1] https://github.com/pabelanger/ansible-role-nodepool
> >> >
> >>
> >> To me, it's unclear how and why we are going to use
> >ansible-role-nodepool.
> >> Could you explain with use-case?
> >>
> >The most basic use case is managing nodepool using ansible, for
> >the purpose of
> >CI.  Bascially, rewrite puppet-nodepool using ansible.  I won't go
> >into the
> >reasoning for that, except to say people do not want to use puppet.
> >
> >Regarding os-ansible-deployment, they are only related due to both
> >using
> >ansible. I wouldn't see os-ansible-deployment using the module,
> >however I would
> >hope to learn best practices and code reviews from the team.
> >
> >Where ever the module lives, I would hope people interested in ansible
> >development would be group somehow.
> >
> >> Thanks,
> >> --
> >> Emilien Macchi
> >>
> >>
> >
> > __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Sergii Golovatiuk]

Vladimir,

I give my +1. We must have different repos for MOS and master node. As a
sample I am giving a case when we need to implement CentOS 7 support but
master node may remain on Centos 6.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Thu, Sep 10, 2015 at 3:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Guys,
>
> I really appreciate your opinions on whether Fuel should be all inclusive
> or not. But the original topic of this thread is different. I personally
> think that in 2015 it is not a big deal to make the master node able to
> access any online host (even taking into account paranoid security
> policies). It is just a matter of network engineering. But it is completely
> out of the scope. What I am suggesting is to align the way how we treat
> different repos, whether upstream or MOS. What I am working on right now is
> I am trying to make Fuel build and delivery approach really flexible. That
> means we need to have as little non-standard ways/hacks/approaches/options
> as possible.
>
> > Why can't we make this optional in the build system? It should be easy
> to implement, is not it?
>
> That is exactly what I am trying to do (make it optional). But I don't
> want it to be yet another boolean variable for this particular thing (MOS
> repo). We have working approach for dealing with repos. Repos can either
> online or local mirrors. We have a tool for making local mirrors
> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
> deploy OpenStack, because he/she still needs upstream to be available.
> Anyway, the user is still forced to do some additional actions. Again, we
> have plans to improve the quality and UX of fuel-createmirror.
>
> Yet another thing I don't want to be on the master node is a bunch of MOS
> repos directories named like
> /var/www/nailgun/2015.1-7.0
> /var/www/nailgun/2014.4-6.1
> with links like
> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
> What does this link mean? Even Fuel developers can be confused. It is
> scary to imagine what users think of it :-) Why should Nailgun and upgrade
> script manage that kind of storage in this exact kind of format? A long
> time ago people invented RPM/DEB repositories, tools to manage them and
> structure for versioning them. We have Perestoika for that and we have
> plans to put all package/mirror related tools in one place (
> github.com/stackforge/fuel-mirror) and make all these tools available out
> of Fuel CI. So, users will be able to easily build their own packages,
> clone necessary repos and manage them in the way which is standard in the
> industry. However, it is out of the scope of the letter.
>
> I also don't like the idea of putting MOS repo on the ISO by default
> because it encourages people thing that ISO is the way of distributing MOS.
> ISO should be nothing more than just a way of installing Fuel from scratch.
> MOS should be distributed via MOS repos. Fuel is available as RPM package
> in RPM MOS repo.
>
>
>
>
>
>
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
> wrote:
>
>> Mike,
>>
>> > still not exactly true for some large enterprises. Due to all the
>> security, etc.,
>> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>>
>> It's their problem, and their policies. We can't and shouldn't handle
>> all possible cases. If some enterprise has "no Internet" policy, I bet
>> it won't be a problem for their IT guys to create an intranet mirror
>> for MOS packages. Moreover, I also bet they do have a mirror for
>> Ubuntu or other Linux distributive. So it basically about approach how
>> to consume our mirrors.
>>
>> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
>> wrote:
>> > Folks
>> >
>> > I think, Mike is completely right here - we need an option to build
>> > all-in-one ISO which can be tried-out/deployed unattendedly without
>> internet
>> > access. Let's let a user make a choice what he wants, not push him into
>> > embarassing situation. We still have many parts of Fuel which make
>> choices
>> > for user that cannot be overriden. Let's not pretend that we know more
>> than
>> > user does about his environment.
>> >
>> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
>> > wrote:
>> >>
>> >> The reason people want offline deployment feature is not because of
>> poor
>> >> connection, but rather the enterprise intranets where getting subnet
>> with
>> >> external access sometimes is a real pain in various body parts.
>> >>
>> >> --
>> >> Best regards,
>> >> Oleg Gelbukh
>> >>
>> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I agree with Vladimir - the idea of online repos is a right way to
>> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
>> >>> reason, and simplify both Fuel and UX. Moreover, take a 

[openstack-dev] [gate] broken by pyeclib 1.0.9 release

[Sean Dague]

The pyeclib 1.0.9 release has broken the gate because Swift is in the
default grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which
doesn't compile correctly with a pip install).

We're working to pin requirements in kilo/juno right now, but anything
that has a grenade job is going to fail until these land.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Vladimir,

* We don't have full ISO anyway
* We don't require to create mirror. When you launch your browser, do you
mean to have mirror of the Internet locally? Probably, no. The same is
here. Internet connection is the common requirement nowadays, but if you
don't have one, you definitely need to have a kind of local copy.

Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
wrote:

> Igor
>
> Having poor access to the internet is a regular use case which we must
> support. This is not a crazy requirement. Not having full ISO makes cloud
> setup harder to complete. Even more, not having hard requirement to create
> a mirror will detract newcomers. I can say that if I were a user and saw a
> requirement to create mirror I would not try the product with comparison to
> the case when I can get a full ISO with all the stuff I need.
>
> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Guys,
>>
>> I really appreciate your opinions on whether Fuel should be all inclusive
>> or not. But the original topic of this thread is different. I personally
>> think that in 2015 it is not a big deal to make the master node able to
>> access any online host (even taking into account paranoid security
>> policies). It is just a matter of network engineering. But it is completely
>> out of the scope. What I am suggesting is to align the way how we treat
>> different repos, whether upstream or MOS. What I am working on right now is
>> I am trying to make Fuel build and delivery approach really flexible. That
>> means we need to have as little non-standard ways/hacks/approaches/options
>> as possible.
>>
>> > Why can't we make this optional in the build system? It should be easy
>> to implement, is not it?
>>
>> That is exactly what I am trying to do (make it optional). But I don't
>> want it to be yet another boolean variable for this particular thing (MOS
>> repo). We have working approach for dealing with repos. Repos can either
>> online or local mirrors. We have a tool for making local mirrors
>> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
>> deploy OpenStack, because he/she still needs upstream to be available.
>> Anyway, the user is still forced to do some additional actions. Again, we
>> have plans to improve the quality and UX of fuel-createmirror.
>>
>> Yet another thing I don't want to be on the master node is a bunch of MOS
>> repos directories named like
>> /var/www/nailgun/2015.1-7.0
>> /var/www/nailgun/2014.4-6.1
>> with links like
>> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
>> What does this link mean? Even Fuel developers can be confused. It is
>> scary to imagine what users think of it :-) Why should Nailgun and upgrade
>> script manage that kind of storage in this exact kind of format? A long
>> time ago people invented RPM/DEB repositories, tools to manage them and
>> structure for versioning them. We have Perestoika for that and we have
>> plans to put all package/mirror related tools in one place (
>> github.com/stackforge/fuel-mirror) and make all these tools available
>> out of Fuel CI. So, users will be able to easily build their own packages,
>> clone necessary repos and manage them in the way which is standard in the
>> industry. However, it is out of the scope of the letter.
>>
>> I also don't like the idea of putting MOS repo on the ISO by default
>> because it encourages people thing that ISO is the way of distributing MOS.
>> ISO should be nothing more than just a way of installing Fuel from scratch.
>> MOS should be distributed via MOS repos. Fuel is available as RPM package
>> in RPM MOS repo.
>>
>>
>>
>>
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Mike,
>>>
>>> > still not exactly true for some large enterprises. Due to all the
>>> security, etc.,
>>> > there are sometimes VPNs / proxies / firewalls with very low
>>> throughput.
>>>
>>> It's their problem, and their policies. We can't and shouldn't handle
>>> all possible cases. If some enterprise has "no Internet" policy, I bet
>>> it won't be a problem for their IT guys to create an intranet mirror
>>> for MOS packages. Moreover, I also bet they do have a mirror for
>>> Ubuntu or other Linux distributive. So it basically about approach how
>>> to consume our mirrors.
>>>
>>> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
>>> wrote:
>>> > Folks
>>> >
>>> > I think, Mike is completely right here - we need an option to build
>>> > all-in-one ISO which can be tried-out/deployed unattendedly without
>>> internet
>>> > access. Let's let a user make a choice what he wants, not push him into
>>> > embarassing situation. We still have many parts of Fuel which make
>>> choices
>>> > for user that cannot be overriden. Let's not pretend that we know more
>>> than
>>> > user does about his environment.
>>> >
>>> > On 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Folks

I guess I need to get you on-site to deploy something at our user's
datacenter. I do want to be able to download an ISO which contains all
packages. This may not be the primary artifact of our software suite, but
we need to have this opportunity to build full ISO with ALL components.
Please, do not narrow down our feature set just by thinking that users do
not need something because we are reluctant to implement this. Just believe
me - users need this opportunity in a lot of deployment cases. It is not
hard to implement it. We do not need to set this as a default option, but
we need to have it. That is my point.

On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Vladimir,
>
> * We don't have full ISO anyway
> * We don't require to create mirror. When you launch your browser, do you
> mean to have mirror of the Internet locally? Probably, no. The same is
> here. Internet connection is the common requirement nowadays, but if you
> don't have one, you definitely need to have a kind of local copy.
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
> wrote:
>
>> Igor
>>
>> Having poor access to the internet is a regular use case which we must
>> support. This is not a crazy requirement. Not having full ISO makes cloud
>> setup harder to complete. Even more, not having hard requirement to create
>> a mirror will detract newcomers. I can say that if I were a user and saw a
>> requirement to create mirror I would not try the product with comparison to
>> the case when I can get a full ISO with all the stuff I need.
>>
>> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Guys,
>>>
>>> I really appreciate your opinions on whether Fuel should be all
>>> inclusive or not. But the original topic of this thread is different. I
>>> personally think that in 2015 it is not a big deal to make the master node
>>> able to access any online host (even taking into account paranoid security
>>> policies). It is just a matter of network engineering. But it is completely
>>> out of the scope. What I am suggesting is to align the way how we treat
>>> different repos, whether upstream or MOS. What I am working on right now is
>>> I am trying to make Fuel build and delivery approach really flexible. That
>>> means we need to have as little non-standard ways/hacks/approaches/options
>>> as possible.
>>>
>>> > Why can't we make this optional in the build system? It should be easy
>>> to implement, is not it?
>>>
>>> That is exactly what I am trying to do (make it optional). But I don't
>>> want it to be yet another boolean variable for this particular thing (MOS
>>> repo). We have working approach for dealing with repos. Repos can either
>>> online or local mirrors. We have a tool for making local mirrors
>>> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
>>> deploy OpenStack, because he/she still needs upstream to be available.
>>> Anyway, the user is still forced to do some additional actions. Again, we
>>> have plans to improve the quality and UX of fuel-createmirror.
>>>
>>> Yet another thing I don't want to be on the master node is a bunch of
>>> MOS repos directories named like
>>> /var/www/nailgun/2015.1-7.0
>>> /var/www/nailgun/2014.4-6.1
>>> with links like
>>> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
>>> What does this link mean? Even Fuel developers can be confused. It is
>>> scary to imagine what users think of it :-) Why should Nailgun and upgrade
>>> script manage that kind of storage in this exact kind of format? A long
>>> time ago people invented RPM/DEB repositories, tools to manage them and
>>> structure for versioning them. We have Perestoika for that and we have
>>> plans to put all package/mirror related tools in one place (
>>> github.com/stackforge/fuel-mirror) and make all these tools available
>>> out of Fuel CI. So, users will be able to easily build their own packages,
>>> clone necessary repos and manage them in the way which is standard in the
>>> industry. However, it is out of the scope of the letter.
>>>
>>> I also don't like the idea of putting MOS repo on the ISO by default
>>> because it encourages people thing that ISO is the way of distributing MOS.
>>> ISO should be nothing more than just a way of installing Fuel from scratch.
>>> MOS should be distributed via MOS repos. Fuel is available as RPM package
>>> in RPM MOS repo.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky >> > wrote:
>>>
 Mike,

 > still not exactly true for some large enterprises. Due to all the
 security, etc.,
 > there are sometimes VPNs / proxies / firewalls with very low
 throughput.

 It's their problem, and their policies. We can't and shouldn't handle
 all possible cases. If some enterprise has "no Internet" policy, I bet

[openstack-dev] [Congress] Ending feature freeze

[Tim Hinrichs]

Hi all,

We're now finished with feature freeze.  We have our first release
candidate and the stable/liberty branch.  So master is once again open for
new features.  Couple of things to note:

1. Documentation.  We should also look through the docs and update them.
Documentation is really important.  There's one doc patch not yet merged,
so be sure to pull that down before editing.  That patch officially
deprecates a number of API calls that don't make sense for the new
distributed architecture.  If you find places where we don't mention the
deprecation, please fix that.

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

2. Bugs.  We should still all be manually testing, looking for bugs, and
fixing them.  This will be true especially as other projects change their
clients, which as we've seen can break our datasource drivers.

All bug fixes first go into master, and then we cherry-pick to
stable/liberty.  Once you've patched a bug on master and it's been merged,
you'll create another change for your bug-fix and push it to review.  Then
one of the cores will +2/+1 it (usually without needing another formal
round of reviews).  Here's the procedure.

// pull down the latest changes for master
$ git checkout master
$ git pull

// create a local branch for stable/liberty and switch to it
$ git checkout origin/stable/liberty -b stable/liberty

// cherry-pick your change from master onto the local stable/liberty
// The -x records the original  in the commit msg
$ git cherry-pick -x 

// Push to review and specify the stable/liberty branch.
// Notice in gerrit that the branch is stable/liberty, not master
$ git review stable/liberty

// Once your change to stable/liberty gets merged, fetch all the new
// changes.

// switch to local version of stable/liberty
$ git checkout stable/liberty

// fetch all the new changes to all the branches
$ git fetch origin

// update your local branch
$ git rebase origin/stable/liberty

Tim
__
OpenStack Development Mailing 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] SOS

[Fox, Kevin M]

Shameless plug:
http://apps.openstack.org

:)

Thanks,
Kevin

From: Gongys [gong_ys2...@aliyun.com]
Sent: Wednesday, September 09, 2015 8:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] SOS

It should be easy, you google it for coreos raw or qcow2 image then import it 
into openstack

Sent from my iPhone

On 2015年9月10日, at 10:53, 蒋吉 > 
wrote:

Hi:
I need a coreos image that supports kubernetes , without it , my boss will 
kick my arse.





__
OpenStack Development Mailing 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-ansible] Security hardening

[Matthew Thode]

On 09/10/2015 09:54 AM, Major Hayden wrote:
> Hey there,
> 
> I've been looking for some ways to harden the systems that are deployed by 
> os-ansible-deployment (soon to be openstack-ansible?) and I've been using the 
> Center for Internet Security (CIS)[1] benchmarks as a potential pathway for 
> that.  There are benchmarks available for various operating systems and 
> applications there.
> 
> Many of the items shown there fall into a few different categories:
> 
>   1) things OSAD should configure
>   2) things deployers should configure
>   3) things nobody should configure (they break the deployment, for example)
> 
> #3 is often quite obvious, but #1 and #2 are a bit more nebulous.  For 
> example, I opened a ticket[2] about getting auditd installed by default with 
> openstack-ansible.  My gut says that many deployers could use auditd since it 
> collects denials from AppArmor and that can help with troubleshooting broken 
> policies.
> 
> Also, I opened another ticket[3] for compressing all logs by default.  This 
> affects availability (part of the information security CIA triad[4]) in a 
> fairly critical way in the long term.
> 
> My question is this: How should I go about determining which security changes 
> should go upstream and which should go into documentation as things deployers 
> should do locally?
> 
> 
> [1] https://benchmarks.cisecurity.org/
> [2] https://bugs.launchpad.net/openstack-ansible/+bug/1491915
> [3] https://bugs.launchpad.net/openstack-ansible/+bug/1493981
> [4] https://en.wikipedia.org/wiki/Information_security#Key_concepts
> 
> --
> Major Hayden
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Sane defaults can't be used?  The two bugs you listed look fine to me as
default things to do.

-- 
Matthew Thode (prometheanfire)



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] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Vladimir,

* We can not put upstream Ubuntu on ISO by default and publish it. We just
can not and thus won't do that.
* If a user wants to have all inclusive ISO, he/she will do it on his/her
own, on his/her own machine, probably using publicly available Fuel tools,
but not using Fuel CI/CD.

I am suggesting nothing more than to make things simpler so that I am able
to implement such tools that could be used to easily build all
inclusive/not inclusive/empty/whatever ISO if one would like to do it.


Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 6:18 PM, Vladimir Kuklin 
wrote:

> Folks
>
> I guess I need to get you on-site to deploy something at our user's
> datacenter. I do want to be able to download an ISO which contains all
> packages. This may not be the primary artifact of our software suite, but
> we need to have this opportunity to build full ISO with ALL components.
> Please, do not narrow down our feature set just by thinking that users do
> not need something because we are reluctant to implement this. Just believe
> me - users need this opportunity in a lot of deployment cases. It is not
> hard to implement it. We do not need to set this as a default option, but
> we need to have it. That is my point.
>
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Vladimir,
>>
>> * We don't have full ISO anyway
>> * We don't require to create mirror. When you launch your browser, do you
>> mean to have mirror of the Internet locally? Probably, no. The same is
>> here. Internet connection is the common requirement nowadays, but if you
>> don't have one, you definitely need to have a kind of local copy.
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Igor
>>>
>>> Having poor access to the internet is a regular use case which we must
>>> support. This is not a crazy requirement. Not having full ISO makes cloud
>>> setup harder to complete. Even more, not having hard requirement to create
>>> a mirror will detract newcomers. I can say that if I were a user and saw a
>>> requirement to create mirror I would not try the product with comparison to
>>> the case when I can get a full ISO with all the stuff I need.
>>>
>>> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Guys,

 I really appreciate your opinions on whether Fuel should be all
 inclusive or not. But the original topic of this thread is different. I
 personally think that in 2015 it is not a big deal to make the master node
 able to access any online host (even taking into account paranoid security
 policies). It is just a matter of network engineering. But it is completely
 out of the scope. What I am suggesting is to align the way how we treat
 different repos, whether upstream or MOS. What I am working on right now is
 I am trying to make Fuel build and delivery approach really flexible. That
 means we need to have as little non-standard ways/hacks/approaches/options
 as possible.

 > Why can't we make this optional in the build system? It should be
 easy to implement, is not it?

 That is exactly what I am trying to do (make it optional). But I don't
 want it to be yet another boolean variable for this particular thing (MOS
 repo). We have working approach for dealing with repos. Repos can either
 online or local mirrors. We have a tool for making local mirrors
 (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
 deploy OpenStack, because he/she still needs upstream to be available.
 Anyway, the user is still forced to do some additional actions. Again, we
 have plans to improve the quality and UX of fuel-createmirror.

 Yet another thing I don't want to be on the master node is a bunch of
 MOS repos directories named like
 /var/www/nailgun/2015.1-7.0
 /var/www/nailgun/2014.4-6.1
 with links like
 /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
 What does this link mean? Even Fuel developers can be confused. It is
 scary to imagine what users think of it :-) Why should Nailgun and upgrade
 script manage that kind of storage in this exact kind of format? A long
 time ago people invented RPM/DEB repositories, tools to manage them and
 structure for versioning them. We have Perestoika for that and we have
 plans to put all package/mirror related tools in one place (
 github.com/stackforge/fuel-mirror) and make all these tools available
 out of Fuel CI. So, users will be able to easily build their own packages,
 clone necessary repos and manage them in the way which is standard in the
 industry. However, it is out of the scope of the letter.

 I also don't like the idea of putting MOS repo on the ISO by default
 because it encourages people thing that ISO is the 

[openstack-dev] [ALL] Instance Users

[Fox, Kevin M]

Many OpenStack projects have a failry common problem. The lack of well defined 
way for OpenStack Instances to talk to the OpenStack its running under.

Each OpenStack project has been working around it themselves in one form or 
another, including Heat, Sahara, Trove, Magnum, and others.

Zaqar and Barbican need credentials to talk to as well, and currently there is 
no good solution.

Developers that build on top of Heat, or do orchestration by other means don't 
have a workaround at present either.

I've written up a proposal to fix this situation here:
https://review.openstack.org/#/c/93/

It is a difficult problem to solve but would be hugely beneficial to may 
projects.

Please, review the spec and add feedback. The more we can work together to 
solve this difficult problem rather then hacking around it individually in our 
individual projects, the better we all will be in the end.

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

Re: [openstack-dev] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

[Jeff Peeler]

On Wed, Sep 9, 2015 at 10:25 PM, Steve Gordon  wrote:

> - Original Message -
> > From: "Jeff Peeler" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > I'd greatly prefer using availability zones/host aggregates as I'm trying
> > to keep the footprint as small as possible. It does appear that in the
> > section "configure scheduler to support host aggregates" [1], that I can
> > configure filtering using just one scheduler (right?). However, perhaps
> > more importantly, I'm now unsure with the network configuration changes
> > required for Ironic that deploying normal instances along with baremetal
> > servers is possible.
> >
> > [1]
> >
> http://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html
>
> Hi Jeff,
>
> I assume your need for a second scheduler is spurred by wanting to enable
> different filters for baremetal vs virt (rather than influencing scheduling
> using the same filters via image properties, extra specs, and boot
> parameters (hints)?
>
> I ask because if not you should be able to use the hypervisor_type image
> property to ensure that images intended for baremetal are directed there
> and those intended for kvm etc. are directed to those hypervisors. The
> documentation [1] doesn't list ironic as a valid value for this property
> but I looked into the code for this a while ago and it seemed like it
> should work... Apologies if you had already considered this.
>
> Thanks,
>
> Steve
>
> [1]
> http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html


I hadn't considered that, thanks. It's still unknown to me though if a
separate compute service is required. And if it is required, how much
segregation is required to make that work.

Not being a networking guru, I'm also unsure if the Ironic setup
instructions to use a flat network is a requirement or is just a sample of
possible configuration. In a brief out of band conversation I had, it does
sound like Ironic can be configured to use linuxbridge too, which I didn't
know was possible.
__
OpenStack Development Mailing 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] FFE request for parallel scrubbing

[Nikhil Komawar]

Hi,

We had a request for this small spec [1] to be in Liberty. It addresses
the concerns around parallel scrubbing performance improvements. The
reason for asking for creating a spec was that it can rather affect
performance negatively in some cases and a config is to help fine tune
that. This will enable operators to run scrubber as per their
requirements. It is a borderline bug/spec for those who wish to look at
the details around such.

So, please vote your thoughts on FFE for this feature. We will decide
the fate of the same by tomorrow (Friday) EOD.

Thanks for putting it together quickly, Hemanth!

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

-- 

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

[openstack-dev] [heat] Backup resources and properties in the delete-path

[Steven Hardy]

Hi all,

So, I've been battling with $subject for the last few days ref [1][2].

The problem I have is that out TestResource references several properties
in the delete (check_delete_complete) path[4], which it turns out doesn't
work very well if those properties refer to parameters via get_param, and
the parameter in the template is added/removed between updates which
fail[3].

Essentially, the confusing dance we do on update with backup stacks and
backup resources bites us, because the backed-up resource ends up referring
to a parameter which doesn't exist (either in
stack.Stack._delete_backup_stack on stack-delete, or in
update.StackUpdate._remove_backup_resource on stack-update.)

As far as I can tell, referencing properties in the delete path is the main
problem here, and it's something we don't do at all AFAICS in any other
resources - the normal pattern is only to refer to the resource_id in the
delete path, and possibly the resource_data (which will work OK after [5]
lands)

So the question is, is it *ever* valid to reference self.properties
in the delete path?  If the answer is no, can we fix TestResource by e.g
storing the properties in resource_data instead?

If we do expect to allow/support refering to properties in the delete path,
the question becomes how to we make it work with the backup resource update
mangling we do atm?  I've posted a hacky workaround for the delete path in
[2], but I don't yet have a solution for the failure on update in
_remove_backup_resource, is it worth expending the effort to work that out
or is TestResource basically doing the wrong thing?

Any ideas much appreciated, as I'd like to clarify the best path forward
before burning a bunch more time on this :)

Thanks!

Steve

[1] https://review.openstack.org/#/c/205754/
[2] https://review.openstack.org/#/c/222176/
[3] https://bugs.launchpad.net/heat/+bug/1494260
[4] 
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/test_resource.py#L209
[5] https://review.openstack.org/#/c/220986/

__
OpenStack Development Mailing 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] Security hardening

[Matthew Thode]

On 09/10/2015 11:33 AM, Major Hayden wrote:
> On 09/10/2015 11:22 AM, Matthew Thode wrote:
>> Sane defaults can't be used?  The two bugs you listed look fine to me as
>> default things to do.
> 
> Thanks, Matthew.  I tend to agree.
> 
> I'm wondering if it would be best to make a "punch list" of CIS benchmarks 
> and try to tag them with one of the following:
> 
>   * Do this in OSAD
>   * Tell deployers how to do this (in docs)
>   * Tell deployers not to do this (in docs)
> 
> That could be lumped in with a spec/blueprint of some sort.  Would that be 
> beneficial?
> 
> 
> __
> OpenStack Development Mailing 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 that'd work, it'd also allow discussion on if something should
be in each section as well.

-- 
Matthew Thode

-- 
-- Matthew Thode (prometheanfire)



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] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Dmitry,

Thanks a lot. That is exactly what I mean. fuel-createmirror can be used by
a user during building ISO, after deployment, never and whenever he/she
wants. Standard approach for all repos. That is it. We just don't need to
put DEB MOS repo on ISO by default, because it makes little sense if
upstream repos are still online.



Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 7:58 PM, Dmitry Pyzhov  wrote:

> Guys,
>
> looks like you’ve started to talk about different things. As I see,
> original proposal was: stop treat MOS DEB repo as a special case and use
> the same flow for all repos. Your use case does not contradict it.
>
> Moreover, it requires standard flow for all repos. ‘Put everything on the
> ISO’ use case should be implemented as a new feature. It is a matter of
> running fuel-createmirror script during ISO build and usage of it during
> master node deployment. It definitely should use mirror as a single object.
> And this object should be compatible with result of the fuel-createmirror
> script usage.
>
> On 10 Sep 2015, at 18:18, Vladimir Kuklin  wrote:
>
> Folks
>
> I guess I need to get you on-site to deploy something at our user's
> datacenter. I do want to be able to download an ISO which contains all
> packages. This may not be the primary artifact of our software suite, but
> we need to have this opportunity to build full ISO with ALL components.
> Please, do not narrow down our feature set just by thinking that users do
> not need something because we are reluctant to implement this. Just believe
> me - users need this opportunity in a lot of deployment cases. It is not
> hard to implement it. We do not need to set this as a default option, but
> we need to have it. That is my point.
>
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Vladimir,
>>
>> * We don't have full ISO anyway
>> * We don't require to create mirror. When you launch your browser, do you
>> mean to have mirror of the Internet locally? Probably, no. The same is
>> here. Internet connection is the common requirement nowadays, but if you
>> don't have one, you definitely need to have a kind of local copy.
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Igor
>>>
>>> Having poor access to the internet is a regular use case which we must
>>> support. This is not a crazy requirement. Not having full ISO makes cloud
>>> setup harder to complete. Even more, not having hard requirement to create
>>> a mirror will detract newcomers. I can say that if I were a user and saw a
>>> requirement to create mirror I would not try the product with comparison to
>>> the case when I can get a full ISO with all the stuff I need.
>>>
>>> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Guys,

 I really appreciate your opinions on whether Fuel should be all
 inclusive or not. But the original topic of this thread is different. I
 personally think that in 2015 it is not a big deal to make the master node
 able to access any online host (even taking into account paranoid security
 policies). It is just a matter of network engineering. But it is completely
 out of the scope. What I am suggesting is to align the way how we treat
 different repos, whether upstream or MOS. What I am working on right now is
 I am trying to make Fuel build and delivery approach really flexible. That
 means we need to have as little non-standard ways/hacks/approaches/options
 as possible.

 > Why can't we make this optional in the build system? It should be
 easy to implement, is not it?

 That is exactly what I am trying to do (make it optional). But I don't
 want it to be yet another boolean variable for this particular thing (MOS
 repo). We have working approach for dealing with repos. Repos can either
 online or local mirrors. We have a tool for making local mirrors
 (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
 deploy OpenStack, because he/she still needs upstream to be available.
 Anyway, the user is still forced to do some additional actions. Again, we
 have plans to improve the quality and UX of fuel-createmirror.

 Yet another thing I don't want to be on the master node is a bunch of
 MOS repos directories named like
 /var/www/nailgun/2015.1-7.0
 /var/www/nailgun/2014.4-6.1
 with links like
 /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
 What does this link mean? Even Fuel developers can be confused. It is
 scary to imagine what users think of it :-) Why should Nailgun and upgrade
 script manage that kind of storage in this exact kind of format? A long
 time ago people invented RPM/DEB repositories, tools to manage them and
 structure for versioning them. We have 

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[Derek Higgins]

On 10/09/15 15:06, James Slagle wrote:

TripleO has added a few new repositories, one of which is
python-tripleoclient[1], the former python-rdomanager-oscplugin.

With the additional repositories, there is an additional review burden
on our core reviewers. There is also the fact that folks who have been
working on the client code for a while when it was only part of RDO
are not TripleO core reviewers.

I think we could help with the additional burden of reviews if we made
two of those people core on python-tripleoclient and tripleo-common
now.

Specifically, the folks I'm proposing are:
Brad P. Crochet 
Dougal Matthews 

The options I see are:
- keep just 1 tripleo acl, and add additional folks there, with a good
faith agreement not to +/-2,+A code that is not from the 2 client
repos.


+1 to doing this, but I would reword the good faith aggreement to "not 
to +/-2,+A code that they are not comfortable/familiar with", in other 
words the same agreement I would expect from any other core. In the same 
way I'll not be adding +2 on tripleoclient code until(if) I know with 
reasonable confidence I'm not doing something stupid.




- create a new gerrit acl in project-config for just these 2 client
repos, and add folks there as needed. the new acl would also contain
the existing acl for tripleo core reviewers
- neither of the above options - don't add these individuals to any
TripleO core team at this time.

The first is what was more or less done when Tuskar was brought under
the TripleO umbrella to avoid splitting the core teams, and it's the
option I'd prefer.

TripleO cores, please reply here with your vote from the above
options. Or, if you have other ideas, you can share those as well :)

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



__
OpenStack Development Mailing 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] [heat] Backup resources and properties in the delete-path

[Zane Bitter]

On 10/09/15 12:53, Steven Hardy wrote:

Hi all,

So, I've been battling with $subject for the last few days ref [1][2].

The problem I have is that out TestResource references several properties
in the delete (check_delete_complete) path[4], which it turns out doesn't
work very well if those properties refer to parameters via get_param, and
the parameter in the template is added/removed between updates which
fail[3].

Essentially, the confusing dance we do on update with backup stacks and
backup resources bites us, because the backed-up resource ends up referring
to a parameter which doesn't exist (either in
stack.Stack._delete_backup_stack on stack-delete, or in
update.StackUpdate._remove_backup_resource on stack-update.)

As far as I can tell, referencing properties in the delete path is the main
problem here, and it's something we don't do at all AFAICS in any other
resources - the normal pattern is only to refer to the resource_id in the
delete path, and possibly the resource_data (which will work OK after [5]
lands)

So the question is, is it *ever* valid to reference self.properties
in the delete path?


I think it's fine to say 'no'.


If the answer is no, can we fix TestResource by e.g
storing the properties in resource_data instead?


They're already stored as self._stored_properties_data; you could just 
reference that instead. (The 'right' way would probably be to use 
"self.frozen_definition().properties(self.properties_schema, 
self.context)", but this is a test resource we're talking about.)



If we do expect to allow/support refering to properties in the delete path,
the question becomes how to we make it work with the backup resource update
mangling we do atm?  I've posted a hacky workaround for the delete path in
[2], but I don't yet have a solution for the failure on update in
_remove_backup_resource, is it worth expending the effort to work that out
or is TestResource basically doing the wrong thing?

Any ideas much appreciated, as I'd like to clarify the best path forward
before burning a bunch more time on this :)

Thanks!

Steve

[1] https://review.openstack.org/#/c/205754/
[2] https://review.openstack.org/#/c/222176/
[3] https://bugs.launchpad.net/heat/+bug/1494260
[4] 
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/test_resource.py#L209
[5] https://review.openstack.org/#/c/220986/

__
OpenStack Development Mailing 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] [Neutron][ML2] ML2 late/early-cycle sprint announcement

[Sukhdev Kapur]

Hi Gal,

I was hoping you will join us in yesterday's ML2 meeting to discuss
further. Anyhow,  we would love your participation in this activity. Please
check the ether pad and see if you could join us in this sprint? If yes,
please sign up so that host can make appropriate arrangements.
Regardless,  please review the document and provide feedback. Also,  see if
you can join next week's meeting.

Thanks
Sukhdev
On Sep 9, 2015 4:50 AM, "Gal Sagie"  wrote:

> Hi Sukhdev,
>
> The common sync framework is something i was also thinking about for some
> time now.
> I think its a very good idea and would love if i could participate in the
> talks (and hopefully the implementation as well)
>
> Thanks
> Gal.
>
> On Wed, Sep 9, 2015 at 9:46 AM, Sukhdev Kapur 
> wrote:
>
>> Folks,
>>
>> We are planning on having ML2 coding sprint on October 6 through 8, 2015.
>> Some are calling it Liberty late-cycle sprint, others are calling it Mitaka
>> early-cycle sprint.
>>
>> ML2 team has been discussing the issues related to synchronization of the
>> Neutron DB resources with the back-end drivers. Several issues have been
>> reported when multiple ML2 drivers are deployed in scaled HA deployments.
>> The issues surface when either side (Neutron or back-end HW/drivers)
>> restart and resource view gets out of sync. There is no mechanism in
>> Neutron or ML2 plugin which ensures the synchronization of the state
>> between the front-end and back-end. The drivers either end up implementing
>> their own solutions or they dump the issue on the operators to intervene
>> and correct it manually.
>>
>> We plan on utilizing Task Flow to implement the framework in ML2 plugin
>> which can be leveraged by ML2 drivers to achieve synchronization in a
>> simplified manner.
>>
>> There are couple of additional items on the Sprint agenda, which are
>> listed on the etherpad [1]. The details of venue and schedule are listed on
>> the enterpad as well. The sprint is hosted by Yahoo Inc.
>> Whoever is interested in the topics listed on the etherpad, is welcome to
>> sign up for the sprint and join us in making this reality.
>>
>> Additionally, we will utilize this sprint to formalize the design
>> proposal(s) for the fish bowl session at Tokyo summit [2]
>>
>> Any questions/clarifications, please join us in our weekly ML2 meeting on
>> Wednesday at 1600 UTC (9AM pacific time) at #openstack-meeting-alt
>>
>> Thanks
>> -Sukhdev
>>
>> [1] - https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint
>> [2] - https://etherpad.openstack.org/p/neutron-mitaka-designsummit
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Dmitry Pyzhov]

Guys,

looks like you’ve started to talk about different things. As I see, original 
proposal was: stop treat MOS DEB repo as a special case and use the same flow 
for all repos. Your use case does not contradict it.

Moreover, it requires standard flow for all repos. ‘Put everything on the ISO’ 
use case should be implemented as a new feature. It is a matter of running 
fuel-createmirror script during ISO build and usage of it during master node 
deployment. It definitely should use mirror as a single object. And this object 
should be compatible with result of the fuel-createmirror script usage.

> On 10 Sep 2015, at 18:18, Vladimir Kuklin  wrote:
> 
> Folks
> 
> I guess I need to get you on-site to deploy something at our user's 
> datacenter. I do want to be able to download an ISO which contains all 
> packages. This may not be the primary artifact of our software suite, but we 
> need to have this opportunity to build full ISO with ALL components. Please, 
> do not narrow down our feature set just by thinking that users do not need 
> something because we are reluctant to implement this. Just believe me - users 
> need this opportunity in a lot of deployment cases. It is not hard to 
> implement it. We do not need to set this as a default option, but we need to 
> have it. That is my point.
> 
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov 
> > wrote:
> Vladimir,
> 
> * We don't have full ISO anyway
> * We don't require to create mirror. When you launch your browser, do you 
> mean to have mirror of the Internet locally? Probably, no. The same is here. 
> Internet connection is the common requirement nowadays, but if you don't have 
> one, you definitely need to have a kind of local copy.
> 
> Vladimir Kozhukalov
> 
> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin  > wrote:
> Igor
> 
> Having poor access to the internet is a regular use case which we must 
> support. This is not a crazy requirement. Not having full ISO makes cloud 
> setup harder to complete. Even more, not having hard requirement to create a 
> mirror will detract newcomers. I can say that if I were a user and saw a 
> requirement to create mirror I would not try the product with comparison to 
> the case when I can get a full ISO with all the stuff I need.
> 
> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov 
> > wrote:
> Guys, 
> 
> I really appreciate your opinions on whether Fuel should be all inclusive or 
> not. But the original topic of this thread is different. I personally think 
> that in 2015 it is not a big deal to make the master node able to access any 
> online host (even taking into account paranoid security policies). It is just 
> a matter of network engineering. But it is completely out of the scope. What 
> I am suggesting is to align the way how we treat different repos, whether 
> upstream or MOS. What I am working on right now is I am trying to make Fuel 
> build and delivery approach really flexible. That means we need to have as 
> little non-standard ways/hacks/approaches/options as possible. 
> 
> > Why can't we make this optional in the build system? It should be easy to 
> > implement, is not it?
> 
> That is exactly what I am trying to do (make it optional). But I don't want 
> it to be yet another boolean variable for this particular thing (MOS repo). 
> We have working approach for dealing with repos. Repos can either online or 
> local mirrors. We have a tool for making local mirrors (fuel-createmirror). 
> Even if we put MOS on the ISO, a user still can not deploy OpenStack, because 
> he/she still needs upstream to be available. Anyway, the user is still forced 
> to do some additional actions. Again, we have plans to improve the quality 
> and UX of fuel-createmirror. 
> 
> Yet another thing I don't want to be on the master node is a bunch of MOS 
> repos directories named like 
> /var/www/nailgun/2015.1-7.0 
> /var/www/nailgun/2014.4-6.1 
> with links like
> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
> What does this link mean? Even Fuel developers can be confused. It is scary 
> to imagine what users think of it :-) Why should Nailgun and upgrade script 
> manage that kind of storage in this exact kind of format? A long time ago 
> people invented RPM/DEB repositories, tools to manage them and structure for 
> versioning them. We have Perestoika for that and we have plans to put all 
> package/mirror related tools in one place (github.com/stackforge/fuel-mirror 
> ) and make all these tools 
> available out of Fuel CI. So, users will be able to easily build their own 
> packages, clone necessary repos and manage them in the way which is standard 
> in the industry. However, it is out of the scope of the letter. 
> 
> I also don't like 

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:
> Sean Dague wrote:
> > Right now, they are all a bunch of files, they can be anywhere. And then
> > you have other files that have to reference these files by path, which
> > can be anywhere. We could just punt in that part and say "punt! every
> > installer and configuration management install needs to solve this on
> > their own." I'm not convinced that's a good answer. The os-brick filters
> > aren't really config. If you change them all that happens is
> > terribleness. Stuff stops working, and you don't know why. They are data
> > to exchange with another process about how to function. Honestly, they
> > should probably be python code that's imported by rootwrap.
> > 
> > Much like the issues around clouds failing when you try to GET /v2 on
> > the Nova API (because we have a bunch of knobs you have to align for SSL
> > termination, and a bunch of deployers didn't), I don't think we should
> > be satisfied with "there's a config for that!" when all that config
> > means is that someone can break their configuration if they don't get it
> > exactly right.
> 
> My quick 2cents on this. Rootwrap was designed as a generic solution to
> wrap privileged calls. That's why filter files are part of its
> "configuration". The problem is, OpenStack needs a pretty precise set of
> those filters to be "configured" to run properly. So it's configuration
> for rootwrap, but not "configuration" for OpenStack.

That makes them sound like data, not configuration. If that's the case,
Python's pkgutil module is an existing API for putting a data file
inside a library and then accessing it. Maybe we should look at moving
the files to a place that lets us use that, instead of requiring any
deployer-based configuration at all. Combining that with the "symbolic"
suggestion from Sean, we would use the package name as the symbol and
there would be a well-defined resource name within that package to use
with pkgutil.get_data() [1].

Doug

[1] https://docs.python.org/2.7/library/pkgutil.html#pkgutil.get_data

> 
> The way it was supposed to work out was that you would have a single
> rootwrap on nodes and every component on that node needing filters would
> drop them in some unique location. A library is just another component
> needing filters, so os-brick could just deploy a few more filters on
> nodes where it's installed.
> 
> The trick is, to increase "security" we promoted usage of per-project
> directories (so that Nova only has access to Nova privileged commands),
> which translated into using a specific config file for Nova rootwrap
> pointing to Nova filters. Now if we are willing to sacrifice that, we
> could have a single directory per-node (/usr/share/rootwrap instead of
> /usr/share/*/rootwrap) that makes most of the interpolation you're
> describing unnecessary.
> 
> Alternatively you could keep project-specific directories and have
> os-brick drop symbolic links to its filters into both nova and
> cinder-specific directories. It's slightly less flexible (since the lib
> now has to know what consumes it) but keeps you from sacrificing "security".
> 
> Now another problem you're describing is that there is no single place
> where those filters end up, depending on the way the projects (or libs)
> are packaged and installed. And it's up to the distros to "fix" the
> filters_path in the configuration file so that it points to every single
> place where those end up. It's a problem (especially when you start to
> install things using multiple concurrent packaging systems), but it's
> not exactly new -- it's just that libraries shipping fliters file are
> even more likely to ship their filters somewhere weird. So maybe we can
> continue to live with that problem we always had, until the privsep
> system completely replaces rootwrap ?
> 

__
OpenStack Development Mailing 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] Security hardening

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/2015 11:22 AM, Matthew Thode wrote:
> Sane defaults can't be used?  The two bugs you listed look fine to me as
> default things to do.

Thanks, Matthew.  I tend to agree.

I'm wondering if it would be best to make a "punch list" of CIS benchmarks and 
try to tag them with one of the following:

  * Do this in OSAD
  * Tell deployers how to do this (in docs)
  * Tell deployers not to do this (in docs)

That could be lumped in with a spec/blueprint of some sort.  Would that be 
beneficial?

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV8bDUAAoJEHNwUeDBAR+xEc0P/3S4qQ/U/TET0ag3hwzN0JBv
G3bbcUHhalnGYq12+nX49rF3f0aa3HOOFcWi/hgFFoS4RXQg9vrxnX6AHE5dWP0u
UgqBM8y24CaYXqPoXnfQC/sNbs7gngduKbpTLFqIUXIS+Rye1uOQSnnHuX4iN0US
u1cTQA6Dv04wORvRIAKlKN1kpGoS/WfKUzVQ7bmorCJjm+azBw0amj50Z7KW9w4X
Ci0VBraKSqojUbhvWgD0so7gcfLwrq9eT5pz67xo26df8cpic/LX1UJ9TBBmS97W
YeDxFcubvPviWxHTwxJEnOjHAN4UF2J4sEn8ExwC5UhfG6vOLt97Je6Bt8inTBh4
tTXgfpLrh50B3xk6l1jFEjglaVaSIMLMhirUUALIaJgMcUsWt5F5utcnvp+4+A41
+MKYn/EhGQIHDe/JPa5Yd37TZTwkTW2jthDWb2lkn72sBfC43L/hnIYcKPq7sLVZ
VOP2hSkoMHVT+My8zUBY/m/gcdVJgR9dHDnTPhAts54P4mZg7iOBlRjk+i4YLmSL
0HA4lDiBbpX1wbDIueeDlSDAnQl0PENRrM8fUiJpI0pJC4AOflqQr2r5Bsb6Cz0V
2q/uPgmv0FRup5efjSF2tGTMGAVarijWlqsPSzkGHBt8KVeR0qlgq1Da8qojesdN
gcW2nS0sHcS6Z90t62dJ
=rN2a
-END 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] Core reviewers for python-tripleoclient and tripleo-common

[Steven Hardy]

On Thu, Sep 10, 2015 at 10:06:31AM -0400, James Slagle wrote:
> TripleO has added a few new repositories, one of which is
> python-tripleoclient[1], the former python-rdomanager-oscplugin.
> 
> With the additional repositories, there is an additional review burden
> on our core reviewers. There is also the fact that folks who have been
> working on the client code for a while when it was only part of RDO
> are not TripleO core reviewers.
> 
> I think we could help with the additional burden of reviews if we made
> two of those people core on python-tripleoclient and tripleo-common
> now.
> 
> Specifically, the folks I'm proposing are:
> Brad P. Crochet 
> Dougal Matthews 

+1 to both!

> The options I see are:
> - keep just 1 tripleo acl, and add additional folks there, with a good
> faith agreement not to +/-2,+A code that is not from the 2 client
> repos.

+1, as others have mentioned I think a common-sense agreement here will be fine 
:)

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] [puppet] [ceilometer] Puppetize OpenStack Aodh

[Emilien Macchi]

Hi,

I'm working [1] on a new Puppet modules for AODH [2].

The good news is that we don't need AODH to have alarming working in
Liberty, so people using puppet to deploy Ceilometer will be able to use
Alarming with future stable/liberty.

I'll of course use puppet-openstack-cookiecutter to create our new
module, I'll ask to Ceilometer team to have a look once we have the
basic structure in place, I have now no idea how to deploy it :-)
I guess looking at how devstack deploys it will help us to understand
the resources that need to be created.

Thanks,

[1] https://review.openstack.org/#/q/topic:puppet/aodh,n,z
[2] https://github.com/openstack/aodh
-- 
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] [rootwrap] rootwrap and libraries - RFC

[Thierry Carrez]

Sean Dague wrote:
> On 09/10/2015 08:23 AM, Thierry Carrez wrote:
>> Now another problem you're describing is that there is no single place
>> where those filters end up, depending on the way the projects (or libs)
>> are packaged and installed. And it's up to the distros to "fix" the
>> filters_path in the configuration file so that it points to every single
>> place where those end up. It's a problem (especially when you start to
>> install things using multiple concurrent packaging systems), but it's
>> not exactly new -- it's just that libraries shipping fliters file are
>> even more likely to ship their filters somewhere weird. So maybe we can
>> continue to live with that problem we always had, until the privsep
>> system completely replaces rootwrap ?
> 
> I do get this is where we came from. I feel like this doesn't really
> address or understand that things are actually quite different when it
> comes to libraries doing rootwrap. We've spent weeks attempting various
> work arounds, and for Liberty just punted and said "os-brick, cinder,
> and nova all must upgrade exactly at the same time". Because that's the
> only solution that doesn't require pages of documentation that
> installers will get wrong some times.
> 
> I don't feel like that's an acceptable solution. And it also means that
> "living" with it means that next cycle we're going to have to say "nova,
> neutron, cinder, os-brick, and vif library must all upgrade at exactly
> the same time". Which is clearly not a thing we want. Had we figured out
> this rootwrap limitation early, os-brick would never have been put into
> Nova because it makes the upgrade process demonstrably worse and more
> fragile.

Right. The only reason why packagers got it right the first time is
because things were a lot simpler back then (Ubuntu was almost the only
game in town) and I personally got involved and made sure they got it
right. I suspect you're right when you assume that if we rely on them to
push the right things at the right places at this stage in the cycle,
that would probably go wrong in a lot of places.

I also agree that os-brick is not worth it if the cost is crappy
upgrades. I'm just unsure adding a layer of config on top will solve
things. I kinda like the idea of not relying on the filesystem at all
(as proposed by Doug) since the filesystem is so deployment-dependent.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

[Gohad, Tushar]

Hi Sean,


To start with, "pip install PyECLib==1.0.9" works fine on a clean trusty 
instance.


Looking at the gate log - 
http://logs.openstack.org/92/115092/11/check/gate-grenade-dsvm/ecfb1f5/logs/grenade.sh.txt.gz#_2015-09-10_13_54_32_069:

-[snip]-

2015-09-10 13:55:52.335 | Collecting PyECLib===1.0.7 (from -c 
/opt/stack/new/requirements/upper-constraints.txt (line 15))
2015-09-10 13:55:52.393 |   Downloading 
http://pypi.region-b.geo-1.openstack.org/packages/source/P/PyECLib/PyECLib-1.0.7.tar.gz
 (8.4MB)

-[snip]-


If requirements.txt has "PyECLib >= 1.0.7", and latest on PyPI is PyECLib 
1.0.9, I wonder why the slave is trying to pull 1.0.7 .. 

Also how is "upper-constaints.txt" used?


Thanks
Tushar



-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Thursday, September 10, 2015 7:44 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

The pyeclib 1.0.9 release has broken the gate because Swift is in the default 
grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which doesn't compile 
correctly with a pip install).

We're working to pin requirements in kilo/juno right now, but anything that has 
a grenade job is going to fail until these land.

-Sean

--
Sean Dague
http://dague.net

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

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

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

[Matt Riedemann]

On 9/10/2015 1:31 PM, Gohad, Tushar wrote:

Hi Sean,


To start with, "pip install PyECLib==1.0.9" works fine on a clean trusty 
instance.


Looking at the gate log - 
http://logs.openstack.org/92/115092/11/check/gate-grenade-dsvm/ecfb1f5/logs/grenade.sh.txt.gz#_2015-09-10_13_54_32_069:

-[snip]-

2015-09-10 13:55:52.335 | Collecting PyECLib===1.0.7 (from -c 
/opt/stack/new/requirements/upper-constraints.txt (line 15))
2015-09-10 13:55:52.393 |   Downloading 
http://pypi.region-b.geo-1.openstack.org/packages/source/P/PyECLib/PyECLib-1.0.7.tar.gz
 (8.4MB)

-[snip]-


If requirements.txt has "PyECLib >= 1.0.7", and latest on PyPI is PyECLib 
1.0.9, I wonder why the slave is trying to pull 1.0.7 ..

Also how is "upper-constaints.txt" used?


Thanks
Tushar



-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Thursday, September 10, 2015 7:44 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

The pyeclib 1.0.9 release has broken the gate because Swift is in the default 
grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which doesn't compile 
correctly with a pip install).

We're working to pin requirements in kilo/juno right now, but anything that has 
a grenade job is going to fail until these land.

-Sean

--
Sean Dague
http://dague.net

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

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



The grenade job is first installing 1.0.9 for kilo since pyeclib is 
uncapped there (well, it was uncapped until today).


Then it goes to install the 'new' side of grenade, which is liberty 
(master) and pyeclib is pinned to 1.0.7 there:


https://github.com/openstack/requirements/blob/master/global-requirements.txt#L125

That's where it's trying to downgrade from 1.0.9 to 1.0.7 and blows up.

--

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-dev] [ceilometer][aodh][gnocchi] Tokyo design session planning

[gord chung]

hi,

as mentioned during today's meeting, since we have our slots for design 
summit, we'll start accepting proposals for the telemetry-related topics 
for the Tokyo summit.


similar to previous design summits, anyone is welcome to propose topics 
related to ceilometer, aodh, gnocchi, or any other 
monitoring/metering/alarming related project.


official proposals can be submitted here: 
https://docs.google.com/spreadsheets/d/1ea_P2k1kNy_SILEnC-5Zl61IFhqEOrlZ5L8VY4-xNB0/edit?usp=sharing


we've also created an etherpad for those wishing to brainstorm ideas 
before adding formal proposal: 
https://etherpad.openstack.org/p/tokyo-ceilometer-design-summit


we have tentatively set submission deadline for October 5, 2015, which 
will be followed by a public vote.


cheers,

--
gord

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

[openstack-dev] Fwd: [kolla] Planned maintenance for Delorean instance - September 14-15

[Jeff Peeler]

FYI

-- Forwarded message --
From: Javier Pena 
Date: Thu, Sep 10, 2015 at 11:50 AM
Subject: [Rdo-list] [delorean] Planned maintenance for Delorean instance -
September 14-15
To: rdo-list 

Dear all,

Due to a planned maintenance of the infrastructure supporting the Delorean
instance (trunk.rdoproject.org), it is expected to be offline between
September 14 (~ 9PM EDT) and September 15 (~ 9PM EDT).

We will be sending updates to the list if there is any additional
information or change in the plans, and keep you updated on the status.

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

Regards,
Javier


Javier Peña, RHCAemail: javier.p...@redhat.com
Senior Software Engineer phone: +34 914148872
EMEA OpenStack Engineering
__
OpenStack Development Mailing 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] [rootwrap] rootwrap and libraries - RFC

[Joshua Harlow]

Just out of curiosity, not 100% related to this thread, but other 
applications also bundle configuration files (for example heat templates 
@ https://github.com/openstack/magnum/tree/master/magnum/templates)


Should there be some guidelines on how these config files are packaged 
and distributed for these projects as well (ie also use pkgutil...); 
probably a good idea to have one so that 
distributors/installers/packaging folk don't have to do something custom 
when packaging these applications/libraries.


-Josh

Thierry Carrez wrote:

Doug Hellmann wrote:

Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:

My quick 2cents on this. Rootwrap was designed as a generic solution to
wrap privileged calls. That's why filter files are part of its
"configuration". The problem is, OpenStack needs a pretty precise set of
those filters to be "configured" to run properly. So it's configuration
for rootwrap, but not "configuration" for OpenStack.

That makes them sound like data, not configuration. If that's the case,
Python's pkgutil module is an existing API for putting a data file
inside a library and then accessing it. Maybe we should look at moving
the files to a place that lets us use that, instead of requiring any
deployer-based configuration at all. Combining that with the "symbolic"
suggestion from Sean, we would use the package name as the symbol and
there would be a well-defined resource name within that package to use
with pkgutil.get_data() [1].


That sounds promising. One trick is that it's the consuming application
that needs to ship the filters, not the library itself (so rootwrap
would have to look into nova resources, not rootwrap resources). Another
trick is that it should require root rights (not nova rights) to change
those resources, otherwise the security model is broken (the whole idea
of rootwrap being to restrict what a compromised nova user can do to the
system).



__
OpenStack Development Mailing 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] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

[Tony Breeds]

Nominations for OpenStack PTLs (Program Technical Leads) are now open and will
remain open until September 17, 05:59 UTC.

All candidacies must be submitted as a text file to the openstack/election
repository as explained on the wiki[0].

In order to be an eligible candidate (and be allowed to vote) in a given PTL
election, you need to have contributed an accepted patch to one of the
corresponding program's projects[1] during the Kilo-Liberty timeframe
(September 18, 2014 06:00 UTC to September 18, 2015 05:59 UTC)

Additional information about the nomination process can be found here:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015

As Tony and I approve candidates, we will update the list of confirmed
candidates on the above wiki page.

Elections will begin on September 18, 2015 and run until after 13:00 UTC
September 24, 2015.

The electorate is requested to confirm their email address in gerrit,
review.openstack.org > Settings > Contact Information >  Preferred Email, prior
to September 17, 2015 so that the emailed ballots are mailed to the correct
email address.

Yours Tony.

[0] 
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#How_to_submit_your_candidacy
[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2015-elections


pgppyiBsyYamo.pgp
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

[openstack-dev] [infra] PTL candidacy

[Jeremy Stanley]

It's time to toss my hat into the ring for Infrastructure PTL, if
you'll have me. I wasn't around at the beginning like my illustrious
predecessors, but I've been a core reviewer and root sysadmin for
OpenStack's community-maintained project infrastructure these past
three years. In that time it's been my pleasure to help further the
tremendous growth we've experienced as a team and within the
OpenStack community as a whole.

https://wiki.openstack.org/user:fungi

As a free software idealist I'm proud not only of what we accomplish
but how we manage to do so without compromising on our standards of
transparency and openness, even when it may inconveniently highlight
new problems we also need to solve. The Infrastructure team serves
as a shining example of how communities can effectively collaborate
and produce while not relying on crutches of proprietary, commercial
tools. Expect me to continue encouraging our community to make the
hard choice in favor of free tools, of being a helpful downstream
for the communities of the tools we use, and of acting as a
responsible upstream to those who wish to reuse the tools we've
written to make our own work possible.

Hurtling now headlong into the Big Tent, our team is facing new and
interesting scaling challenges. I won't claim to possess easy
answers to the dilemmas awaiting us, but am confident in our ability
to solve them and will do everything I can to support you all to
that end. Great strides have already been made toward reorganizing,
delegating and distributing our decision making, and I expect us to
continue in those efforts as well as whatever new solutions we will
inevitably identify together.

The PTL's role is that of a communicator, facilitator, coordinator
and mentor; if these are the ways you'd like to see me spend the
next six months, then I'd appreciate your vote.
-- 
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

[openstack-dev] [Horizon]Let's take care of our integration tests

[Douglas Fish]

It looks like we've reached the point where our Horizon integration tests
are functional again.  Thanks for your work on this Timur! (Offer for
beer/hug at the next summit still stands)

I'd like to have these tests voting again ASAP, but I understand that might
be a bit risky at this point. We haven't yet proven that these tests will
be stable over the long term.

I encourage all of the reviewers to keep the integration tests in mind as
we are reviewing code. Keep an eye on the status of the
gate-horizon-dsvm-integration test. It's failure would be great reason to
hand out a -1!

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] [keystone] PTL non-candidacy

[Lance Bragstad]

Best of luck in your new adventures, and thanks for all your hard work!

On Thu, Sep 10, 2015 at 5:28 PM, Dolph Mathews 
wrote:

> Thank you for all your work, Morgan! Good luck with the opportunity to
> write some code again :)
>
> On Thu, Sep 10, 2015 at 4:40 PM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wrote:
>
>> As I outlined (briefly) in my recent announcement of changes (
>> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
>> ) I will not be running for PTL of Keystone this next cycle (Mitaka). The
>> role of PTL is a difficult but extremely rewarding job. It has been amazing
>> to see both Keystone and OpenStack grow.
>>
>> I am very pleased with the accomplishments of the Keystone development
>> team over the last year. We have seen improvements with Federation,
>> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
>> releasing a dedicated authentication library, cross-project initiatives
>> around improving the Service Catalog, and much, much more. I want to thank
>> each and every contributor for the hard work that was put into Keystone and
>> its associated projects.
>>
>> While I will be changing my focus to spend more time on the general needs
>> of OpenStack and working on the Public Cloud story, I am confident in those
>> who can, and will, step up to the challenges of leading development of
>> Keystone and the associated projects. I may be working across more
>> projects, but you can be assured I will be continuing to work hard to see
>> the initiatives I helped start through. I wish the best of luck to the next
>> PTL.
>>
>> I guess this is where I get to write a lot more code soon!
>>
>> See you all (in person) in Tokyo!
>> --Morgan
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [infra] PTL non-candidacy

[Joshua Hesketh]

On Fri, Sep 11, 2015 at 6:56 AM, Jeremy Stanley  wrote:

> On 2015-09-10 13:27:53 -0700 (-0700), James E. Blair wrote:
> [...]
> > I do not plan to run for PTL in the next cycle.
> [...]
>
> Thanks for the awesome job you did as PTL these last cycles. I hope
> you enjoy a much-deserved break from the post, and I'm looking
> forward to the new Zuul! ;)
>

Indeed! Your efforts on infra have been both tireless and amazing. Thanks
for all you do for open source!

Cheers,
Josh
__
OpenStack Development Mailing 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] [heat] Backup resources and properties in the delete-path

[Steve Baker]

On 11/09/15 05:02, Zane Bitter wrote:

On 10/09/15 12:53, Steven Hardy wrote:

Hi all,

So, I've been battling with $subject for the last few days ref [1][2].

The problem I have is that out TestResource references several 
properties
in the delete (check_delete_complete) path[4], which it turns out 
doesn't
work very well if those properties refer to parameters via get_param, 
and

the parameter in the template is added/removed between updates which
fail[3].

Essentially, the confusing dance we do on update with backup stacks and
backup resources bites us, because the backed-up resource ends up 
referring

to a parameter which doesn't exist (either in
stack.Stack._delete_backup_stack on stack-delete, or in
update.StackUpdate._remove_backup_resource on stack-update.)

As far as I can tell, referencing properties in the delete path is 
the main

problem here, and it's something we don't do at all AFAICS in any other
resources - the normal pattern is only to refer to the resource_id in 
the
delete path, and possibly the resource_data (which will work OK after 
[5]

lands)

So the question is, is it *ever* valid to reference self.properties
in the delete path?


I think it's fine to say 'no'.


I know of a case where this is not no.

For a SoftwareDeployment which has work to do during DELETE the 
properties need to be accessed to get the config containing the DELETE 
work. There were convergence functional tests failing because the 
properties were not populated during delete:

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


If the answer is no, can we fix TestResource by e.g
storing the properties in resource_data instead?


They're already stored as self._stored_properties_data; you could just 
reference that instead. (The 'right' way would probably be to use 
"self.frozen_definition().properties(self.properties_schema, 
self.context)", but this is a test resource we're talking about.)


If we do expect to allow/support refering to properties in the delete 
path,
the question becomes how to we make it work with the backup resource 
update
mangling we do atm?  I've posted a hacky workaround for the delete 
path in

[2], but I don't yet have a solution for the failure on update in
_remove_backup_resource, is it worth expending the effort to work 
that out

or is TestResource basically doing the wrong thing?

Any ideas much appreciated, as I'd like to clarify the best path forward
before burning a bunch more time on this :)

Thanks!

Steve

[1] https://review.openstack.org/#/c/205754/
[2] https://review.openstack.org/#/c/222176/
[3] https://bugs.launchpad.net/heat/+bug/1494260
[4] 
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/test_resource.py#L209

[5] https://review.openstack.org/#/c/220986/

__ 


OpenStack Development Mailing 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] [ceilometerclient] Updating global-requirements caps.

[Tony Breeds]

Hi all,
In trying to fix a few stable/juno issues we need to release a new version
of ceilometerclient for stable/juno.  This email is to try and raise awareness
so that if the proposal is bonkers [1] we can come up with something better.

This isn't currently possible due to the current caps in juno and kilo.

The proposed fix is to:

. update g-r in master (liberty): python-ceilometerclient>=1.2
  https://review.openstack.org/#/c/222386/
. update g-r in stable/kilo: python-ceilometerclient>=1.1.1,<1.2 
. release a sync of stable/kilo g-r to stable/kilo python-ceilometerclient as 
1.1.1
. update g-r in stable/juno: python-ceilometerclient<1.1.0,!=1.0.13,!=1.0.14 
. release 1.0.15 with a sync of stable/juno g-r

The point is, leave 1.0.x for juno, 1.1.x for kilo and >=1.2 for liberty

This is being tracked as: 
https://bugs.launchpad.net/python-ceilometerclient/+bug/1494516

There is a secondary issue if getting the (juno) gate in a shape where we can
actually do all of that.

Yours Tony.
[1] Bonkers is a recognized technical term right?


pgpgGhKVfkuMn.pgp
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] custom lbaas driver

[Stephen Balukoff]

Srikumar--

I'm not aware of any particular write-up. The best advice I have is to
start with the logging noop driver and refer to the reference haproxy
namespace driver to see what these are doing to implement the functionality
of LBaaS v2.

Sorry! I wish I had better news for you.

Stephen

On Fri, Sep 4, 2015 at 10:36 AM, Srikumar Chari 
wrote:

> Hello,
>
> I am trying to write an custom lbaas v2.0 driver. Was wondering if there's
> a document on how to go about that. I see a number of implementations as
> part of the source code but they all seem to be different. For instance
> HAProxy is completely different when compared to the other vendors. I am
> assuming that HAProxy is the "standard" as it is the default load balancer
> for OpenStack. Is there a design doc or some kinda write up?
>
> This thread was the closest I could get to a write-up:
> https://openstack.nimeyo.com/21628/openstack-dev-neutron-lbaas-need-help-with-lbaas-drivers
> .
>
> I guess I could reverse engineering the HAProxy namespace driver but I am
> probably going to miss some of the design elements. Any help/pointers/links
> would be great.
>
> thanks
> Sri
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
OpenStack Development Mailing 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]Let's take care of our integration tests

[David Lyle]

I completely agree about monitoring for integration test failures and
blocking until the failure is corrected.

The hope is to make sure we've stabilized the integration testing
framework a bit before reenabling to vote.

Thanks Timur, I know this has been a considerable undertaking.

David

On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:
> It looks like we've reached the point where our Horizon integration tests
> are functional again.  Thanks for your work on this Timur! (Offer for
> beer/hug at the next summit still stands)
>
> I'd like to have these tests voting again ASAP, but I understand that might
> be a bit risky at this point. We haven't yet proven that these tests will be
> stable over the long term.
>
> I encourage all of the reviewers to keep the integration tests in mind as we
> are reviewing code. Keep an eye on the status of the
> gate-horizon-dsvm-integration test. It's failure would be great reason to
> hand out a -1!
>
> 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-dev] [oslo][release] stable/juno branch creation

[Tony Breeds]

On Wed, Aug 26, 2015 at 03:11:56PM -0400, Doug Hellmann wrote:
> Tony,
> 
> Thanks for digging into this!
> 
> I should be able to help, but right now we're ramping up for the L3
> feature freeze and there are a lot of release-related activities going
> on. Can this wait a few weeks for things to settle down again?

Hi Doug,
Just following up on this.

When you have time can you please:

* create a new stable/juno branch in oslo.utils based on 1.4.0
   - https://bugs.launchpad.net/oslo.utils/+bug/1488746/comments/3
* create a new stable/juno branch in oslotest based on 1.3.0
   - https://bugs.launchpad.net/oslotest/+bug/1488752/comments/3
   - https://bugs.launchpad.net/oslotest/+bug/1488752/comments/4

Once they're there I'll upload the g-r sync patches and then Robert has
promised to help me with the release side of things.  I have to admit I'm a
little terrified ;P

I'll keep an eye on these stable branches and try to keep them clean in the
gate.

Yours Tony.


pgpA4IeiNI6OS.pgp
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] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

[Tony Breeds]

On Fri, Sep 11, 2015 at 10:24:17AM +1000, Tony Breeds wrote:
> Nominations for OpenStack PTLs (Program Technical Leads) are now open and will
> remain open until September 17, 05:59 UTC.
> 
> All candidacies must be submitted as a text file to the openstack/election
> repository as explained on the wiki[0].
> 
> In order to be an eligible candidate (and be allowed to vote) in a given PTL
> election, you need to have contributed an accepted patch to one of the
> corresponding program's projects[1] during the Kilo-Liberty timeframe
> (September 18, 2014 06:00 UTC to September 18, 2015 05:59 UTC)
> 
> Additional information about the nomination process can be found here:
> https://wiki.openstack.org/wiki/PTL_Elections_September_2015
> 
> As Tony and I approve candidates, we will update the list of confirmed

Of course s/Tony/Tristan/  Sorry.

> candidates on the above wiki page.
> 
> Elections will begin on September 18, 2015 and run until after 13:00 UTC
> September 24, 2015.
> 
> The electorate is requested to confirm their email address in gerrit,
> review.openstack.org > Settings > Contact Information >  Preferred Email, 
> prior
> to September 17, 2015 so that the emailed ballots are mailed to the correct
> email address.
> 
> Yours Tony.
> 
> [0] 
> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#How_to_submit_your_candidacy
> [1] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2015-elections



> __
> OpenStack Development Mailing 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 Tony.


pgpxzRNZtuRnN.pgp
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

[openstack-dev] [keystone] PTL non-candidacy

[Morgan Fainberg]

As I outlined (briefly) in my recent announcement of changes (
https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
) I will not be running for PTL of Keystone this next cycle (Mitaka). The
role of PTL is a difficult but extremely rewarding job. It has been amazing
to see both Keystone and OpenStack grow.

I am very pleased with the accomplishments of the Keystone development team
over the last year. We have seen improvements with Federation,
Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
releasing a dedicated authentication library, cross-project initiatives
around improving the Service Catalog, and much, much more. I want to thank
each and every contributor for the hard work that was put into Keystone and
its associated projects.

While I will be changing my focus to spend more time on the general needs
of OpenStack and working on the Public Cloud story, I am confident in those
who can, and will, step up to the challenges of leading development of
Keystone and the associated projects. I may be working across more
projects, but you can be assured I will be continuing to work hard to see
the initiatives I helped start through. I wish the best of luck to the next
PTL.

I guess this is where I get to write a lot more code soon!

See you all (in person) in Tokyo!
--Morgan
__
OpenStack Development Mailing 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] [keystone] PTL non-candidacy

[Dolph Mathews]

Thank you for all your work, Morgan! Good luck with the opportunity to
write some code again :)

On Thu, Sep 10, 2015 at 4:40 PM, Morgan Fainberg 
wrote:

> As I outlined (briefly) in my recent announcement of changes (
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
> ) I will not be running for PTL of Keystone this next cycle (Mitaka). The
> role of PTL is a difficult but extremely rewarding job. It has been amazing
> to see both Keystone and OpenStack grow.
>
> I am very pleased with the accomplishments of the Keystone development
> team over the last year. We have seen improvements with Federation,
> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
> releasing a dedicated authentication library, cross-project initiatives
> around improving the Service Catalog, and much, much more. I want to thank
> each and every contributor for the hard work that was put into Keystone and
> its associated projects.
>
> While I will be changing my focus to spend more time on the general needs
> of OpenStack and working on the Public Cloud story, I am confident in those
> who can, and will, step up to the challenges of leading development of
> Keystone and the associated projects. I may be working across more
> projects, but you can be assured I will be continuing to work hard to see
> the initiatives I helped start through. I wish the best of luck to the next
> PTL.
>
> I guess this is where I get to write a lot more code soon!
>
> See you all (in person) in Tokyo!
> --Morgan
>
> __
> OpenStack Development Mailing 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-Infra] [infra] PTL non-candidacy

[Edgar Magana]

Thanks James for the great work done on the team!

I am sure we are going to hear a lot more from you in the community  ;-)

Edgar




On 9/10/15, 1:27 PM, "James E. Blair"  wrote:

>Hi,
>
>I've been the Infrastructure PTL for some time now and I've been
>fortunate to serve during a time when we have not only grown the
>OpenStack project to a scale that we only hoped we would attain, but
>also we have grown the Infrastructure project itself into truly
>uncharted territory.
>
>Serving as a PTL is a very rewarding experience that takes a good deal
>of time and attention.  I would like to focus my time and energy on
>diving deeper into technical projects, including quite a bit of work
>that I would like to accomplish on Zuul, so I do not plan to run for PTL
>in the next cycle.
>
>Fortunately there are people in our community that have broad
>involvement with all aspects of the Infrastructure project and we have
>no shortage of folks who like interacting with and supporting others in
>their work.  I wish whoever follows the best of luck while I look
>forward to writing some code.
>
>-Jim
>
>___
>OpenStack-Infra mailing list
>openstack-in...@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
__
OpenStack Development Mailing 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] [neutron] RFE process question

[James Dempsey]

On 10/09/15 19:39, Gal Sagie wrote:
> Hi James,
> 
> I think that https://review.openstack.org/#/c/216021/ might be what you are
> looking for.
> Please review and see that it fits your requierment.
> Hopefully this gets approved for next release and i can start working on
> it, if you would like to join
> and contribute (or anyone in your team) i would love any help on that.

Thanks for the link; looks like a great feature. I'm not sure it is the
best fit for my use case though.

My user story is: Users can see human-readable security group
descriptions in Horizon because the security group model contains a
description field, but no such field exists for security group rules.
This makes it very confusing for users who have to manage complex
security groups.

I agree that one could encode descriptions as tags, but the problem I
see is that API consumers(Horizon, Users) would have to agree on some
common encoding.  For example... To expose a security group rule
description in Horizon, horizon would have to apply and read tags like
'description:SSH Access for Mallory'.

With a tags-based implementation, if a user wants the description for a
security group rule via the API, they have to get the security group,
then filter the tags according to whatever format horizon chose to
encode the description as.

This is in contrast to getting the description of a security group: Get
the security group and access the description attribute.

I think that resource tags are great, but this seems like a
non-intuitive workaround for a specific data model problem: Security
Groups have descriptions, but Security Group Rules do not.

Am I making sense?

Cheers,
James


> 
> Thanks
> Gal.
> 
> On Thu, Sep 10, 2015 at 8:59 AM, Armando M.  wrote:
> 
>>
>> On 10 September 2015 at 11:04, James Dempsey 
>> wrote:
>>
>>> Greetings Devs,
>>>
>>> I'm very excited about the new RFE process and thought I'd test it by
>>> requesting a feature that is very often requested by my users[1].
>>>
>>> There are some great docs out there about how to submit an RFE, but I
>>> don't know what should happen after the submission to launchpad. My RFE
>>> bug seems to have been untouched for a month and I'm unsure if I've done
>>> something wrong. So, here are a few questions that I have.
>>>
>>>
>>> 1. Should I be following up on the dev list to ask for someone to look
>>> at my RFE bug?
>>> 2. How long should I expect it to take to have my RFE acknowledged?
>>> 3. As an operator, I'm a bit ignorant as to whether or not there are
>>> times during the release cycle during which there simply won't be
>>> bandwidth to consider RFE bugs.
>>> 4. Should I be doing anything else?
>>>
>>> Would love some guidance.
>>>
>>
>> you did nothing wrong, the team was simply busy going through the existing
>> schedule. Having said that, you could have spared a few more words on the
>> use case and what you mean by annotations.
>>
>> I'll follow up on the RFE for more questions.
>>
>> Cheers,
>> Armando
>>
>>
>>>
>>> Cheers,
>>> James
>>>
>>> [1] https://bugs.launchpad.net/neutron/+bug/1483480
>>>
>>> --
>>> James Dempsey
>>> Senior Cloud Engineer
>>> Catalyst IT Limited
>>> +64 4 803 2264
>>> --

__
OpenStack Development Mailing 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] [sahara] mitaka summit session ideas

[michael mccune]

hey all,

i started an etherpad for us to collect ideas about our session for the 
mitaka summit.


https://etherpad.openstack.org/p/mitaka-sahara-session-plans

please drop any thoughts or suggestions about the summit there.

thanks,
mike

__
OpenStack Development Mailing 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] Vote for our weekly meeting schedule

[Hongbin Lu]

Hi team,

Currently, magnum weekly team meeting is scheduled at Tuesday UTC1600 and 
UTC2200. As our team growing, contributors from different timezones joined and 
actively participated. I worried that our current meeting schedule (which was 
decided a long time ago) might not be update-to-date to reflect the convenience 
of our contributors. Therefore, a doodle pool was created:

http://doodle.com/poll/76ix26i2pdz89vz4

The proposed time slots were made according to an estimation of current 
geographic distribution of active contributors. Please feel free to ping me if 
you want to propose additional time slots. Finally, please vote your meeting 
time. The team will decide whether to adjust the current schedule according to 
the results. Thanks.

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

[openstack-dev] [neutron][nova] - removing "INVALID drop" iptables rule

[Kevin Benton]

Hi,

I have a patch out in which I want to make sure any allow rules are
processed before the rule that drops packets conntrack deems as INVALID.[1]
This rule interferes with setups where conntrack might not see the first
part of a TCP handshake because of encapsulation in a load balancer
direct-service-return setup.

What I would like to know is why the rule was added in the first place and
if there are any concerns with not processing it before the allow rules.
The only thing I can see that it's really stopping is SYN-ACK probing to
ports the security groups are configured to allow, in which case a SYN
probe would likely work just as well.

Any feedback here or directly on the patch would be great.

1. https://review.openstack.org/#/c/218517/


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

Re: [openstack-dev] [oslo][release] stable/juno branch creation

[Davanum Srinivas]

+1 from me!

Thanks,
Dims

On Thu, Sep 10, 2015 at 7:50 PM, Tony Breeds 
wrote:

> On Wed, Aug 26, 2015 at 03:11:56PM -0400, Doug Hellmann wrote:
> > Tony,
> >
> > Thanks for digging into this!
> >
> > I should be able to help, but right now we're ramping up for the L3
> > feature freeze and there are a lot of release-related activities going
> > on. Can this wait a few weeks for things to settle down again?
>
> Hi Doug,
> Just following up on this.
>
> When you have time can you please:
>
> * create a new stable/juno branch in oslo.utils based on 1.4.0
>- https://bugs.launchpad.net/oslo.utils/+bug/1488746/comments/3
> * create a new stable/juno branch in oslotest based on 1.3.0
>- https://bugs.launchpad.net/oslotest/+bug/1488752/comments/3
>- https://bugs.launchpad.net/oslotest/+bug/1488752/comments/4
>
> Once they're there I'll upload the g-r sync patches and then Robert has
> promised to help me with the release side of things.  I have to admit I'm a
> little terrified ;P
>
> I'll keep an eye on these stable branches and try to keep them clean in the
> gate.
>
> Yours Tony.
>



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