Re: [openstack-dev] Acknowledging Jim Blair's work on the TC

[Joshua Hesketh]

Absolutely, +1!

Thanks very much for all you do Jim.

On Sat, Apr 2, 2016 at 6:06 AM, Anita Kuno  wrote:

> Jim is an incumbent on the TC this election and he didn't run. I'm
> posting this to express my thanks to Jim for his work and dedication on
> the TC.
>
> Jim, I think your commitment to open source, spanning many years before
> OpenStack, and your dedication to governance process, are qualities I
> admire very much and I'm grateful you were able to voice your opinions
> on the TC from October 2013 until now.
>
> Thank you for taking your turn and thank you as well for allowing others
> a chance to take theirs.
>
> Thank you, Jim,
> Anita.
>
> __
> OpenStack Development Mailing 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] [monasca][release] missing build artifacts

[Hochmuth, Roland M]

Hi Doug, You had mentioned issues with three repos:

1. monasca-ceilometer
2. monasca-log-api
3. monasca-thresh

All the repos that have Python code I believe are in reasonable shape with 
respect to the Python deliverables except for the following two repos:

1. monasca-ceilometer
2. monasca-log-api

I'm not sure we should attempt to resolve these two repos for the Mitaka 
release, but we can try. It might be too late. They aren't in heavy usage and 
are relatively new.


monasca-thresh is a pure Java component.

In the process of looking at monasca-thresh it looks like there is a general 
issue with all the Java deliverables. All the Java jars are built and uploaded 
in their respective folders such as, 
http://tarballs.openstack.org/ci/monasca-thresh/. Note the "ci". However, we 
don't move the jars that are in this directory up a level to 
http://tarballs.openstack.org/monasca-thresh/. It looks like that needs to get 
resolved.


A proposal that I think would resolve this is as follows:

1. Update versions of Java jars in the pom.xml for each project to something 
like 2.0 on the stable/mitaka branch. This will result in a new jar file being 
created with a nice version and name. Note, this step isn't necessary, but if 
we did this we would have a nice version for Mitaka.
2. Figure out how to copy the jars over to their respective folders in 
http://tarballs.openstak.org. For Python I think the script that does this is 
publish-to-pypi, but for Java code, not sure exactly what needs to be done.

I think the two steps above would get us in compliance again for monasca-thresh 
and all the Java code in the other repos.

Does that seem like a reasonable plan at this point?

Regards --Roland



On 4/1/16, 2:36 PM, "Doug Hellmann"  wrote:

>Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
>> Hi Doug, Sorry, this is our first release and we want to do the right thing.
>> 
>> monasca-ceilometer is the code that plugs into the Ceilometer publisher and 
>> Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca 
>> API and use Monasca as a storage backend. We don't create a pypi for this 
>> component.
>
>How do you users receive that code and install it? We at least need
>a tarball built. If you don't want to publish to pypi, you can use
>the job definitions that the Python server projects use to build
>artifacts.
>
>> monasca-log-api is probably not set up completely, but it should be similar 
>> to the monasca-api.
>> 
>> monasca-thresh remains purely Java code. There is a build, but it isn't a 
>> Python build so there isn't a tox.ini. Not sure how to deliver this, but the 
>> current java build overwrites the jar each time it builds so it sounds like 
>> that would need to be fixed.
>
>Are those JAR files going somewhere we could link to?
>
>> 
>> I guess, judging by the issues, I don't quite understand what "deliverables" 
>> are. I was thinking it was the tagged code, but obviously it includes the 
>> build too. It sounds like we have more work ahead of us.
>
>Most of our distributors want a tarball or sdist or other artifact they
>can use to build a package from. For the Python-based apps, we have
>templates you can use in the zuul/layout.yaml file to introduce those
>jobs into the right zuul queues. The release or infra teams can help you
>identify the right template to use.
>
>> Let me know how you want to proceed.
>
>We only want to be linking to things we're actually publishing. The
>first patch I mentioned removes the links so the Monasca projects
>that don't have builds. The second patch removes the projects
>entirely, but if we can update the page to link to a downloadable
>artifact (rather than just a git repo tag) then we can keep the
>projects in the list. We can get downloadable artifacts by having
>you add build jobs and then having the release team tag again as a
>new release candidate, or if there are already artifacts somewhere
>(like the JAR file) we can set up the releases repo to link there.
>
>Doug
>
>> 
>> Regards --Roland
>> 
>> On 4/1/16, 1:21 PM, "Doug Hellmann"  wrote:
>> 
>> >Monasca team,
>> >
>> >We noticed in our audit of the links on
>> >http://releases.openstack.org/mitaka/index.html that the links to
>> >the build artifacts for monasca-ceilometer, monasca-log-api, and
>> >monasca-thresh point to missing files. These repositories either
>> >don't seem to have any real build jobs configured in
>> >openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
>> >set up correctly (or both), so it's not clear how tagging is producing
>> >a release for you.
>> >
>> >For now, we are disabling links to the artifacts for those repos
>> >via https://review.openstack.org/300457 but we're also planning to
>> >remove them from the official Mitaka page since there don't
>> >appear to be any actual related deliverables
>> >(https://review.openstack.org/300619).
>> >
>> >It would be good to 

[openstack-dev] [nova] We have our first implemented blueprint in Newton

[Matt Riedemann]

Congratulations to Nikola for being the first to get a blueprint 
implemented in Newton [1][2].


I would give a shiny trophy if I had one.

Just 34 more of the already approved blueprints to go. :)

Seriously though, this is nice to see so quickly, and I'm seeing good 
progress on some of the other re-approved blueprints already.


[1] https://blueprints.launchpad.net/nova/newton
[2] 
https://blueprints.launchpad.net/nova/+spec/sriov-pf-passthrough-neutron-port


--

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

Re: [openstack-dev] [nova] Which SSL ca_file does a person use, really?

[ZZelle]

>
> However, I'd be willing to bet there's some cloud out there where at
> least one of these services is owned by a separate team than Nova, who
> uses a different CA than the rest of things.
>

 It's not really a constraint as a cafile can contain one or more CA(s).

Typical examples :

* /usr/ssl/certs/ca-certificates.crt in Ubuntu
* /etc/pki/tls/certs/ca-bundle.crt in idontremember
* cacert.pem in requests python package deployed using pip

Cédric/ZZelle
__
OpenStack Development Mailing 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] Team meeting this Monday at 2100 UTC

[Armando M.]

Hi neutrinos,

A kind reminder for next week's meeting. More on the agenda [1].

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings
__
OpenStack Development Mailing 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] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag

[Steven Dake (stdake)]

Please see my review here as requested in this thread [1]:

https://review.openstack.org/300698


The purpose of this review is two fold:

  1.  Permit sponsoring companies of single vendor projects or projects with 
low company affiliation diversity to allow their own security experts to sign 
off on a threat analysis, acting as a third party..
  2.  Enable scaling of the OSSA and VMT processes by permitting projects to 
self-audit, self-review, or self-threat analyze with the condition that an 
impartial third party take responsibility for approving the audit, review, or 
threat analysis.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/091075.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

[Edgar Magana]

Congratulations Assaf!

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, March 31, 2016 at 5:48 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

Hi folks,

Assaf's tenacity is a great asset for the Neutron team at large. I believe that 
the drivers team would benefit from that tenacity, and therefore I would like 
to announce him to be a new member of the Neutron Drivers team [1].

At the same time, I would like to thanks mestery as he steps down. Mestery has 
been instrumental in many decisions taken by this team and for spearheading the 
creation of the very team back in the Juno days.

As I mentioned in the past, having a propension to attendance, and desire to 
review of RFEs puts you on the right foot to join the group, whose members are 
rotated regularly so that everyone is given the opportunity to grow, and no-one 
burns out.

The team [1] meets regularly on Thursdays [2], and anyone is welcome to attend.

Please, join me in welcome Assaf to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing 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] [Tricircle] Naming convention

[Shinobu Kinjo]

One of examples is:

"""
 tricircle/db/api.py
"""
authorize_quota_class_context(context, class_name):

# This could become:

auth_quota_class_ctx(ctx, class_name):

# If we put some comment for this, this also could become:

"""
  Function: Ensure a request has right permission to given the project.
  @ctx: user context
  @class: class name
"""
auth_quota_ctx(ctx, class):

Point here is, honestly not only name but also appropriate length of comment.
What do you think?

Cheers,
Shinobu


On Sat, Apr 2, 2016 at 8:20 AM, joehuang  wrote:
> yes, good idea, could you point out or
>  report a bug which are not good naming.
>
> thanks.
>
> Sent from HUAWEI AnyOffice
> 发件人：shinobu.kj
> 收件人：openstack-dev,
> 时间：2016-04-02 06:21:50
> 主题:[openstack-dev] [Tricircle] Naming convention
>
> Hi Team,
>
> Probably it's worth thinking of naming convention for classes, methods
> or whatever we define in source codes.
>
> Some names are lengthy and there might be no consistency. At the
> moment it's fine. But once this project gets growing, situation would
> become chaotic and could cause bugs.
>
> What do you think?
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> GitHub:
> shinobu-x
> Blog:
> Life with Distributed Computational System based on OpenSource
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

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

Re: [openstack-dev] [congress][release] missing build artifacts

[Tim Hinrichs]

Hi Doug,

Thanks for letting us know.  Here's what we're intending...
- We'd like to release the server code for Mitaka.
- We release the client to Pypi, so that's already taken care of.
- We haven't moved our docs off of readthedocs yet, so we're taking care of
that as well.

I gave a +1 to your patch for adding openstack-server-release-jobs to zuul.
I also pushed a congress-only patch for the same, thinking that's probably
what you actually wanted us to do.
https://review.openstack.org/#/c/300682/

I gave a -1 to your patch that removes all the Congress deliverables from
openstack/releases, thinking that we can have this sorted out quickly.  The
job we're missing just produces a tarball and uploads it, right?  We've
been manually doing releases up to this point, which is why we didn't have
the job in place.
https://review.openstack.org/300644

I didn't touch your change on the artifact-link-mode, since it seems like a
short-term solution that may go in before we get everything sorted.
https://review.openstack.org/300457

Tim

On Fri, Apr 1, 2016 at 1:23 PM Doug Hellmann  wrote:

> Congress team,
>
> We noticed in our audit of the links on
> http://releases.openstack.org/mitaka/index.html that the links to
> the build artifacts for congress point to missing files. The
> repository doesn't seem to have any real build jobs configured in
> openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> how tagging is producing a release for you.
>
> For now, we are disabling links to the artifacts for those repos
> via https://review.openstack.org/300457 but we're also planning to
> remove them from the official Mitaka page since there don't
> appear to be any actual related deliverables
> (https://review.openstack.org/300644).
>
> It would be good to understand what your intent is for builds. Can
> you follow up here on this thread with some details?
>
> Thanks,
> 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

Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

[Rodrigo Duarte]

On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish 
wrote:

> On Thu, Mar 31, 2016 at 11:38:55AM -0400, Minying Lu wrote:
> > Hi all,
> >
> > I'm working on resource federation at the Massachusetts Open Cloud. We
> want
> > to implement functional test on the k2k federation, which requires
> > authentication with both a local keystone and a remote keystone (in a
> > different cloud installation). It also requires a K2K/SAML assertion
> > exchange with the local and remote keystones. These functions are not
> > implemented in the current tempest.lib.service library, so I'm adding
> code
> > to the service library.
> >
> > My question is, is it possible to adapt keystoneauth python clients? Or
> do
> > you prefer implementing it with http requests.
>
> So tempest's clients have to be completely independent. That's part of
> tempest's
> design points about testing APIs, not client implementations. If you need
> to add
> additional functionality to the tempest clients that's fine, but pulling in
> keystoneauth isn't really an option.
>

++


>
> >
> > And since this test requires a lot of environment set up including: 2
> > separate cloud installations, shibboleth, creating mapping and protocols
> on
> > remote cloud, etc. Would it be within the scope of tempest's mission?
>
> From the tempest perspective it expects the environment to be setup and
> already
> exist by the time you run the test. If it's a valid use of the API, which
> I'd
> say this is and an important one too, then I feel it's fair game to have
> tests
> for this live in tempest. We'll just have to make the configuration options
> around how tempest will do this very explicit to make sure the necessary
> environment exists before the tests are executed.
>

Another option is to add those tests to keystone itself (if you are not
including tests that triggers other components APIs). See
https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests


>
> The fly in the ointment for this case will be CI though. For tests to live
> in
> tempest they need to be verified by a CI system before they can land. So to
> land the additional testing in tempest you'll have to also ensure there is
> a
> CI job setup in infra to configure the necessary environment. While I think
> this is a good thing to have in the long run, it's not necessarily a small
> undertaking.
>

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


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [bifrost][ironic][release] missing build artifacts

[Julia Kreger]

On Fri, Apr 1, 2016 at 4:48 PM, Doug Hellmann  wrote:

> Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07 -0400:
> > Ironic/Bifrost team,
> >



>
> > It would be good to understand what your intent is for builds. Can
> > you follow up here on this thread with some details?
> >
>

First time partial user of the deliverables release tagging and didn't
realize that we were
missing the configuration necessary to push a tag up to tarballs.o.o. Would
landing
300646 and then reverting it after 300474 has landed result in the
artifacts being built
and pushed to tarballs.o.o?


>
> I forgot to mention that https://review.openstack.org/#/c/300474
> includes some changes to add the simple server publishing jobs. If you
> want to use those, please +1 the patch.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tricircle] Naming convention

[Shinobu Kinjo]

Hi Team,

Probably it's worth thinking of naming convention for classes, methods
or whatever we define in source codes.

Some names are lengthy and there might be no consistency. At the
moment it's fine. But once this project gets growing, situation would
become chaotic and could cause bugs.

What do you think?

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] [magnum] Split k8s-client in separate python package

[Hongbin Lu]

Dims,

Thanks for splitting the k8sclient code out. Below is my answer to your 
question.

- Should this be a new openstack/ repo?
Yes, I think so. We need it in openstack namespace in order to leverage the 
openstack infra for testing and packaging.

- Would the Magnum team own the repo and use the new python package?
If this library is mainly used by Magnum, I think Magnum team has no problem to 
own it. If it is also used by other projects, I am afraid Magnum team won't 
have enough bandwidth to support it. In such case, it is better to have other 
teams to share the ownership.

Best regards,
Hongbin

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: April-01-16 3:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Split k8s-client in separate python package

Team,

I've been meaning to do this for a while. Short version, see repo:
https://github.com/dims/python-k8sclient/

Long version:
- Started from the magnum repo.
- pulled out just ./magnum/common/pythonk8sclient
- preserved entire history in case we had to go back
- reorganized directory structure
- ran openstack cookie cutter and added generated files
- added a test that actually works against a live k8s :)
  
https://github.com/dims/python-k8sclient/blob/master/k8sclient/tests/test_k8sclient.py

Question:
- Should this be a new openstack/ repo?
- Would the Magnum team own the repo and use the new python package?

Thanks,
Dims


-- 
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 Development Mailing 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] Meeting time preferences for OSC team

[reedip banerjee]

Possible options:

A)
1. even week: *E.1*

2. odd week: *O.3*

B)

1. even week: *E.4*

2. odd week: *O.3*

>Dear All,

>This is regarding deciding meeting time for OSC team to facilitate
>appropriate time for APAC guys.
>We are planning to have meeting on alternate weeks for this purpose.

>Some of the suggestions are:

>*E.1* Every two weeks (on even weeks) on Thursday at 1300 UTC in
>#openstack-meeting (IRC webclient)
>*E.2* Every two weeks (on even weeks) on Tuesday at 1500 UTC in
>#openstack-meeting (IRC webclient)
>*E.3* Every two weeks (on even weeks) on Friday at 1500 UTC in
>#openstack-meeting-4 (IRC webclient)
>*E.4* Every two weeks (on even weeks) on Thursday at 1600 UTC in
>#openstack-meeting (IRC webclient)


>*O.1* Every two weeks (on odd weeks) on Tuesday at 1400 UTC in
>#openstack-meeting-4 (IRC webclient)
>*O.2* Every two weeks (on odd weeks) on Wednesday at 1400 UTC in
>#openstack-meeting-3 (IRC webclient)
>*O.3* Every two weeks (on odd/even weeks) on Thursday at 1900 UTC in
>#openstack-meeting (IRC webclient)  -- our regular meeting time

>Kindly share your preffered time(select only one for each even/odd weeks
>and share in your response in below format).

>1. even week: *E.1/E.2/E.3/E.4*/  ?
>2. odd week:  *O.1/O.2/O.3*  ?

>(response sample):
>1. even week: *E.2*
>2. odd week: *O.3*

>Best Regards,
>Sheel Rana


Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing 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] Floating IPs and Public IPs are not equivalent

[Kevin Benton]

The main barrier to this is that we need to stop using the
'external_network_bridge = br-ex' option for the L3 agent and define a
bridge mapping on the L2 agent. Otherwise the external network is treated
as a special case and the VMs won't actually be able to get wired into the
external network.

On Thu, Mar 31, 2016 at 12:58 PM, Sean Dague  wrote:

> On 03/31/2016 01:23 PM, Monty Taylor wrote:
> > Just a friendly reminder to everyone - floating IPs are not synonymous
> > with Public IPs in OpenStack.
> >
> > The most common (and growing, thank you to the beta of the new
> > Dreamcompute cloud) configuration for Public Clouds is directly assign
> > public IPs to VMs without requiring a user to create a floating IP.
> >
> > I have heard that the require-floating-ip model is very common for
> > private clouds. While I find that even stranger, as the need to run NAT
> > inside of another NAT is bizarre, it is what it is.
> >
> > Both models are common enough that pretty much anything that wants to
> > consume OpenStack VMs needs to account for both possibilities.
> >
> > It would be really great if we could get the default config in devstack
> > to be to have a shared direct-attached network that can also have a
> > router attached to it and provider floating ips, since that scenario
> > actually allows interacting with both models (and is actually the most
> > common config across the OpenStack public clouds)
>
> If someone has the the pattern for what that config looks like,
> especially if it could work on single interface machines, that would be
> great.
>
> The current defaults in devstack are mostly there for legacy reasons
> (and because they work everywhere), and for activation energy to getting
> a new robust work everywhere setup.
>
> -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] Floating IPs and Public IPs are not equivalent

[Kevin Benton]

Or if you don't like floating IPs, it means you can have floating IPs
available to only one tenant you dislike. :)

On Fri, Apr 1, 2016 at 11:39 AM, Monty Taylor  wrote:

> On 04/01/2016 12:00 PM, Fox, Kevin M wrote:
>
>> And with external rbac in mitaka, you can finally have private floating
>> ip's. :)
>>
>
> Wha. I mean.
>
> My face. It just fell off.
>
> 
>> *From:* Monty Taylor
>> *Sent:* Thursday, March 31, 2016 10:23:22 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] Floating IPs and Public IPs are not equivalent
>>
>>
>> Just a friendly reminder to everyone - floating IPs are not synonymous
>> with Public IPs in OpenStack.
>>
>> The most common (and growing, thank you to the beta of the new
>> Dreamcompute cloud) configuration for Public Clouds is directly assign
>> public IPs to VMs without requiring a user to create a floating IP.
>>
>> I have heard that the require-floating-ip model is very common for
>> private clouds. While I find that even stranger, as the need to run NAT
>> inside of another NAT is bizarre, it is what it is.
>>
>> Both models are common enough that pretty much anything that wants to
>> consume OpenStack VMs needs to account for both possibilities.
>>
>> It would be really great if we could get the default config in devstack
>> to be to have a shared direct-attached network that can also have a
>> router attached to it and provider floating ips, since that scenario
>> actually allows interacting with both models (and is actually the most
>> common config across the OpenStack public clouds)
>>
>> Monty
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

[Kevin Benton]

Welcome! \o/

On Fri, Apr 1, 2016 at 12:04 PM, Carl Baldwin  wrote:

> Welcome, Assaf!
>
> On Thu, Mar 31, 2016 at 6:48 PM, Armando M.  wrote:
> > Hi folks,
> >
> > Assaf's tenacity is a great asset for the Neutron team at large. I
> believe
> > that the drivers team would benefit from that tenacity, and therefore I
> > would like to announce him to be a new member of the Neutron Drivers team
> > [1].
> >
> > At the same time, I would like to thanks mestery as he steps down.
> Mestery
> > has been instrumental in many decisions taken by this team and for
> > spearheading the creation of the very team back in the Juno days.
> >
> > As I mentioned in the past, having a propension to attendance, and
> desire to
> > review of RFEs puts you on the right foot to join the group, whose
> members
> > are rotated regularly so that everyone is given the opportunity to grow,
> and
> > no-one burns out.
> >
> > The team [1] meets regularly on Thursdays [2], and anyone is welcome to
> > attend.
> >
> > Please, join me in welcome Assaf to the team.
> >
> > Cheers,
> > Armando
> >
> > [1]
> >
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> > [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> >
> >
> __
> > OpenStack Development Mailing 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Doug Hellmann]

Excerpts from Matt Kassawara's message of 2016-04-01 12:38:02 -0600:
> Hi,
> 
> I didn't see this e-mail until now because I'm busy trying to update and
> test the installation guide in time for the Mitaka release. As a primary
> contributor to the installation guide for about six releases including
> restructuring it a couple of times, I think I can explain why we do what we
> do.
> 
> First, a little history about the guide...
> 
> The installation guide often provides the first experience for people
> trying OpenStack. Thus, the guide should provide not just a good
> experience, but a great experience. We can all agree on wanting more
> adoption of OpenStack. For many people, launching an instance and being
> able to access it feels like summiting a mountain. My first experience with
> OpenStack involved nearly a month of trying to install Grizzly with neutron
> for evaluation purposes using the installation guide. It didn't work.
> Looking at various support channels such as IRC and ask.openstack.org, most
> people were stuck at the same place without any answers. I finally
> determined that nova lacked the configuration telling it to use neutron for
> networking, so it kept attempting to build nova networks when those
> components didn't exist. I opened a bug and someone fixed it. Shortly
> thereafter, I began addressing the seemingly infinite number of
> installation guide bugs. However, the cycle of frustration was beginning to
> repeat itself with Havana. The reactive method of finding a problem,
> opening a bug, and waiting for a patch simply wasn't working for our
> audience of potential operators, not developers, that just expect it to
> work.
> 
> So, I proposed changing the guide from reactive to proactive. In other
> words, we update and test the guide prior to release for every distribution
> it supports. We began this approach with Icehouse and saw a decrease in
> bugs and frustration. Furthermore, when assisting people through various
> support channels, we could more easily determine whether the problem was a
> just a typo or a problem with the guide. However, proactively maintaining
> the guide put a significant burden on the contributors. Gone were the days
> of "fire-and-forget" patches. Almost all patches require actual testing,
> sometimes across several distributions. Updating the guide for the next
> release requires performing full installations, often several times per
> distribution, until we can successfully install and test all services
> without deviating from the instructions. A considerable amount of work,
> especially about a month before release when contributors who involve
> themselves in other projects are also busy trying to release those
> projects. Thus, the installation guide has seen a decrease in contributions
> making it increasingly difficult to update and test for each release.
> Furthermore, the installation guide receives little, if any, support from
> most projects including "core" projects. Even if those projects know about
> the installation guide, most assume that the documentation team magically
> updates it for every release to deploy each service in a basic fashion
> accounting for configuration changes and recommendations. From the
> perspective of a project developer, those updates probably seem simple.
> Just read the code, track patches, and maybe attend some meetings, right?
> From the perspective of installation guide contributors, we can't involve
> ourselves that deeply in one project let alone nearly ten projects. Imagine
> us trying to consider big tent projects? We have begged projects for years
> to provide resources for maintaining the installation guide. If nothing
> else, provide some notes on an etherpad indicating what we should change.
> At this point in the game, we shouldn't have to resort to deprecation
> messages or gate job configurations to determine how to deploy a service.
> 
> Regarding use of distribution packages instead of source...
> 
> The guide uses distribution packages instead of source because our audience
> is usually familiar with them and they eliminate a significant number of
> steps in an already complex and often overwhelming process. For example,
> packages manage dependencies and provide init scripts. The installation
> guide teaches our audience how to deploy the most common OpenStack services
> for evaluation purposes. For example, our audience quickly learns that each
> service typically depends on keystone, a database, and a message queue.
> After getting comfortable with the installation process, we recommend
> implementing redundancy/security on top of a basic installation and
> eventually tooling for a production deployment.
> 
> Distribution packages aren't perfect by any means. First, they usually lag
> the upstream release cycle by several weeks which forces us to update and
> test changes using milestones, sometimes not even the last "feature-freeze"
> milestone, after the first release candidate 

Re: [openstack-dev] [neutron]: Neutron naming legal issues

[Fox, Kevin M]

This kind of thing happens all the time, and usually its not reasonable to 
enforce across different types of things. Especially since neutrons a type of 
space/science thing and so is nova, from which it spawned. I think its highly 
unlikely that someone will confuse the software and the commic character.

And in todays day and age it is basically impossibe to use a word and not find 
something that exists already. Its hard enough in the software world not to 
with another piece of software, let alone a commic book character that a lot of 
folks never have heard of.

Its unreasonable to rename neutron again and imho it will make marvel look bad 
to try and force it through.

Thanks,
Kevin


From: Jimmy Akin
Sent: Thursday, March 31, 2016 10:46:41 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron]: Neutron naming legal issues


Dear Neutrinos,

We've been following the project for quite some time.
To our satisfaction the project seems to have done well; the base line of
features that were available to the networking component of OpenStack
(then nova-network) has grown quite a bit and seem to have gained a
successful momentum with the communities, both development and
operators.

However, Neutron appears to be a trademarked name [1], and
after thoroughly discussing the issue with our and Marvel' legal departments
both sides have reached the conclusion that a naming scheme is an obligatory 
amendment and unfortunately is the only viable option.

An obvious resolution to this issue is reverting the old "Quantum" name back.
However, this is subject to change and review from the PTL and as such, we'll 
shortly propose a relevant change to the review system.
We anticipate the review process to be be swift, to avoid further legal 
implications.

Sincerely,
Jimmy J. Akin,
CIO,John F. Kennedy Space Center.

[1] https://en.wikipedia.org/wiki/Neutron_(Marvel_Comics)


__
OpenStack Development Mailing 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]: Neutron naming legal issues

[Doug Wiegley]

I vote for “Big Giant Pencil”.  We can call it BGP for short.

doug

> On Apr 1, 2016, at 2:15 PM, Sean M. Collins  wrote:
> 
> I for one, have grown fond of "Mutnauq" while doing the DevStack neutron
> re-write ;)
> 
> 
> -- 
> Sean M. Collins
> 
> __
> OpenStack Development Mailing 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] [Ceilosca][Neutron][Monasca]

[Hochmuth, Roland M]

Hi Rubab, I'm not that knowledge on networking/neutron, and still in learn 
mode, but it sounds like it would be useful. This is an area that I am starting 
to get more involved with. There is a potential design summit session that 
Armando and I are looking into hosting on monitoring Neutron.

Ceilosca was just a name that we created as a combination of Ceilometer and 
Monasca. There isn't an official Ceilosca project/repo. However, there is a 
repo called monasca-ceilometer at, 
https://github.com/openstack/monasca-ceilometer, which contains a Ceilometer 
publisher, that translates/sends samples to the Monasca API. The repo also 
contains a storage driver that allows you to use Monasca as a backend for 
Ceilometer. This code is quite stable, has undergone an extensive amount of 
testing and is ready for deployment.

Regards --Roland

From: Rubab Syed >
Reply-To: OpenStack List 
>
Date: Tuesday, March 1, 2016 at 9:25 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Ceilosca][Neutron][Monasca]

Hi all,

I'm planning to write a plugin for Monasca that would enable router's traffic 
monitoring per subnet per tenant. For that purpose, I'm using Neutron l3 
metering extension [1] that allows you to filter traffic based on CIDRs.

My concerns:

- Now given the fact that this extension can be used to create labels and rules 
for particular set of IPs and ceilometer can be used to meter the bandwidth 
based on this data and monasca publisher for ceilometer is also available, 
would that plugin be useful somehow? Where are we at ceilosca right now?

- Even though ceilometer allows to meter bandwidth at l3 level, we still have 
to create explicit labels and rules for all subnets attached to a router. In a 
production environment where there could be multiple routers belonging to 
multiple tenants, isn't it a bit of a work? I was wondering if I could automate 
the label and rule creation process. My script would automatically detect 
subnets and create rules per interface of router. It would help in ceilosca as 
well and can be used by the router plugin (given plugin is not redundant work). 
Comments?


[1] https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth


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

Re: [openstack-dev] [congress][release] missing build artifacts

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-04-01 16:21:07 -0400:
> Congress team,
> 
> We noticed in our audit of the links on
> http://releases.openstack.org/mitaka/index.html that the links to
> the build artifacts for congress point to missing files. The
> repository doesn't seem to have any real build jobs configured in
> openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> how tagging is producing a release for you.
> 
> For now, we are disabling links to the artifacts for those repos
> via https://review.openstack.org/300457 but we're also planning to
> remove them from the official Mitaka page since there don't
> appear to be any actual related deliverables
> (https://review.openstack.org/300644).
> 
> It would be good to understand what your intent is for builds. Can
> you follow up here on this thread with some details?
> 
> Thanks,
> Doug

I forgot to mention that https://review.openstack.org/#/c/300474
includes some changes to add the simple server publishing jobs. If you
want to use those, please +1 the patch.

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] [bifrost][ironic][release] missing build artifacts

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07 -0400:
> Ironic/Bifrost team,
> 
> We noticed in our audit of the links on
> http://releases.openstack.org/mitaka/index.html that the links to
> the build artifacts for bifrost point to missing files. The repository
> doesn't seem to have any real build jobs configured in
> openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> how tagging is producing a release for you.
> 
> For now, we are disabling links to the artifacts for those repos
> via https://review.openstack.org/300457 but we're also planning to
> remove them from the official Mitaka page since there don't
> appear to be any actual related deliverables
> (https://review.openstack.org/300646).
> 
> It would be good to understand what your intent is for builds. Can
> you follow up here on this thread with some details?
> 
> Thanks,
> Doug
> 

I forgot to mention that https://review.openstack.org/#/c/300474
includes some changes to add the simple server publishing jobs. If you
want to use those, please +1 the patch.

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] [sahara][release] missing build artifacts

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-04-01 16:27:42 -0400:
> Sahara team,
> 
> We noticed in our audit of the links on
> http://releases.openstack.org/mitaka/index.html that the links to
> the build artifacts for sahara-extras point to missing files. The
> repository doesn't seem to have any real build jobs configured in
> openstack-infra/project-config/zuul/layout.yaml, so it's not clear
> how tagging is producing a release for you.
> 
> For now, we are disabling links to the artifacts for those repos
> via https://review.openstack.org/300457 but we're also planning to
> remove them from the official Mitaka page since there don't appear
> to be any actual related deliverables
> (https://review.openstack.org/300647).
> 
> It would be good to understand what your intent is for builds. Can
> you follow up here on this thread with some details?
> 
> Thanks,
> Doug
> 

I forgot to mention that https://review.openstack.org/#/c/300474
includes some changes to add the simple server publishing jobs. If you
want to use those, please +1 the patch.

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] [monasca][release] missing build artifacts

[Doug Hellmann]

Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +:
> Hi Doug, Sorry, this is our first release and we want to do the right thing.
> 
> monasca-ceilometer is the code that plugs into the Ceilometer publisher and 
> Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca 
> API and use Monasca as a storage backend. We don't create a pypi for this 
> component.

How do you users receive that code and install it? We at least need
a tarball built. If you don't want to publish to pypi, you can use
the job definitions that the Python server projects use to build
artifacts.

> monasca-log-api is probably not set up completely, but it should be similar 
> to the monasca-api.
> 
> monasca-thresh remains purely Java code. There is a build, but it isn't a 
> Python build so there isn't a tox.ini. Not sure how to deliver this, but the 
> current java build overwrites the jar each time it builds so it sounds like 
> that would need to be fixed.

Are those JAR files going somewhere we could link to?

> 
> I guess, judging by the issues, I don't quite understand what "deliverables" 
> are. I was thinking it was the tagged code, but obviously it includes the 
> build too. It sounds like we have more work ahead of us.

Most of our distributors want a tarball or sdist or other artifact they
can use to build a package from. For the Python-based apps, we have
templates you can use in the zuul/layout.yaml file to introduce those
jobs into the right zuul queues. The release or infra teams can help you
identify the right template to use.

> Let me know how you want to proceed.

We only want to be linking to things we're actually publishing. The
first patch I mentioned removes the links so the Monasca projects
that don't have builds. The second patch removes the projects
entirely, but if we can update the page to link to a downloadable
artifact (rather than just a git repo tag) then we can keep the
projects in the list. We can get downloadable artifacts by having
you add build jobs and then having the release team tag again as a
new release candidate, or if there are already artifacts somewhere
(like the JAR file) we can set up the releases repo to link there.

Doug

> 
> Regards --Roland
> 
> On 4/1/16, 1:21 PM, "Doug Hellmann"  wrote:
> 
> >Monasca team,
> >
> >We noticed in our audit of the links on
> >http://releases.openstack.org/mitaka/index.html that the links to
> >the build artifacts for monasca-ceilometer, monasca-log-api, and
> >monasca-thresh point to missing files. These repositories either
> >don't seem to have any real build jobs configured in
> >openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
> >set up correctly (or both), so it's not clear how tagging is producing
> >a release for you.
> >
> >For now, we are disabling links to the artifacts for those repos
> >via https://review.openstack.org/300457 but we're also planning to
> >remove them from the official Mitaka page since there don't
> >appear to be any actual related deliverables
> >(https://review.openstack.org/300619).
> >
> >It would be good to understand what your intent is for builds. Can
> >you follow up here on this thread with some details?
> >
> >Thanks,
> >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] [sahara][release] missing build artifacts

[Doug Hellmann]

Sahara team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for sahara-extras point to missing files. The
repository doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear
how tagging is producing a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't appear
to be any actual related deliverables
(https://review.openstack.org/300647).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?

Thanks,
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-dev] [bifrost][ironic][release] missing build artifacts

[Doug Hellmann]

Ironic/Bifrost team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for bifrost point to missing files. The repository
doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear
how tagging is producing a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't
appear to be any actual related deliverables
(https://review.openstack.org/300646).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?

Thanks,
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-dev] [congress][release] missing build artifacts

[Doug Hellmann]

Congress team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for congress point to missing files. The
repository doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear
how tagging is producing a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't
appear to be any actual related deliverables
(https://review.openstack.org/300644).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?

Thanks,
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] [neutron]: Neutron naming legal issues

[Sean M. Collins]

I for one, have grown fond of "Mutnauq" while doing the DevStack neutron
re-write ;)


-- 
Sean M. Collins

__
OpenStack Development Mailing 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] Meeting time preferences for OSC team

[Sheel Rana Insaan]

Dear All,

This is regarding deciding meeting time for OSC team to facilitate
appropriate time for APAC guys.
We are planning to have meeting on alternate weeks for this purpose.

Some of the suggestions are:

*E.1* Every two weeks (on even weeks) on Thursday at 1300 UTC in
#openstack-meeting (IRC webclient)
*E.2* Every two weeks (on even weeks) on Tuesday at 1500 UTC in
#openstack-meeting (IRC webclient)
*E.3* Every two weeks (on even weeks) on Friday at 1500 UTC in
#openstack-meeting-4 (IRC webclient)
*E.4* Every two weeks (on even weeks) on Thursday at 1600 UTC in
#openstack-meeting (IRC webclient)


*O.1* Every two weeks (on odd weeks) on Tuesday at 1400 UTC in
#openstack-meeting-4 (IRC webclient)
*O.2* Every two weeks (on odd weeks) on Wednesday at 1400 UTC in
#openstack-meeting-3 (IRC webclient)
*O.3* Every two weeks (on odd/even weeks) on Thursday at 1900 UTC in
#openstack-meeting (IRC webclient)  -- our regular meeting time

Kindly share your preffered time(select only one for each even/odd weeks
and share in your response in below format).

1. even week: *E.1/E.2/E.3/E.4*/  ?
2. odd week:  *O.1/O.2/O.3*  ?

(response sample):
1. even week: *E.2*
2. odd week: *O.3*

Best Regards,
Sheel Rana
__
OpenStack Development Mailing 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] [monasca][release] missing build artifacts

[Hochmuth, Roland M]

Hi Doug, Sorry, this is our first release and we want to do the right thing.

monasca-ceilometer is the code that plugs into the Ceilometer publisher and 
Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca 
API and use Monasca as a storage backend. We don't create a pypi for this 
component.

monasca-log-api is probably not set up completely, but it should be similar to 
the monasca-api.

monasca-thresh remains purely Java code. There is a build, but it isn't a 
Python build so there isn't a tox.ini. Not sure how to deliver this, but the 
current java build overwrites the jar each time it builds so it sounds like 
that would need to be fixed.

I guess, judging by the issues, I don't quite understand what "deliverables" 
are. I was thinking it was the tagged code, but obviously it includes the build 
too. It sounds like we have more work ahead of us.

Let me know how you want to proceed.

Regards --Roland



On 4/1/16, 1:21 PM, "Doug Hellmann"  wrote:

>Monasca team,
>
>We noticed in our audit of the links on
>http://releases.openstack.org/mitaka/index.html that the links to
>the build artifacts for monasca-ceilometer, monasca-log-api, and
>monasca-thresh point to missing files. These repositories either
>don't seem to have any real build jobs configured in
>openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
>set up correctly (or both), so it's not clear how tagging is producing
>a release for you.
>
>For now, we are disabling links to the artifacts for those repos
>via https://review.openstack.org/300457 but we're also planning to
>remove them from the official Mitaka page since there don't
>appear to be any actual related deliverables
>(https://review.openstack.org/300619).
>
>It would be good to understand what your intent is for builds. Can
>you follow up here on this thread with some details?
>
>Thanks,
>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

Re: [openstack-dev] [release][requirements] global requirements master branch is unfrozen

[Davanum Srinivas]

I've cleaned up my votes as well.

Thanks,
Dims

On Fri, Apr 1, 2016 at 2:20 PM, Doug Hellmann  wrote:
> Folks,
>
> The global requirements repo (openstack/requirements) is now open for
> Newton-related changes. I've removed the -2 votes from all of the
> patches I froze, but there may be some from other reviewers. Please
> contact them directly if your patch still has a procedural block, but
> keep in mind that during the week right before the release they may not
> have time to do more than remove their -2.
>
> 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



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

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

[Steven Dake (stdake)]

Graham,

Responses inline.

On 4/1/16, 8:50 AM, "Hayes, Graham"  wrote:

>>> On 3/31/16, 12:15 PM, "michael mccune"  wrote:
>>>
 
> >>>
 one of the big questions seems to be who should be doing these
analysis,
 especially given that the ossp has not formally codified the practice
 yet, and the complexity involved. although currently the
 vulnerability:managed tag suggests that a third party review should be
 done, this may prove difficult to scale in practice. i feel that it
 would be in the best interests of the wider openstack community if the
 ossp works towards creating instructional material that can empower
the
 project teams to start their own analyses.

 ultimately, having a third-party review of a project is worthy goal,
but
 this has to be tempered with the reality that a single team will not
be
 able to scale out and provide thorough analyses for all projects. to
 that extent, the ossp should work, initially, to help a few teams get
 these analyses completed and in the process create a set of useful
tools
 (docs, guides, diagrams, foil-hat wearing pamphlets) to help further
the
 effort.

 i would like to propose that the threat analysis portion of the
 vulnerability:managed tag be modified with the goal of having the
 project teams create their own analyses, with an extended third-party
 review to be performed afterwards. in this respect, the scale issue
can
 be addressed, as well as the issue of project domain knowledge. it
makes
 much more sense to me to have the project team creating the initial
work
 here as they will know the areas, and architectures, that will need
the
 most attention.

 

>
>If a team has already done a TA (e.g. as part of an internal product
>TA) (and produced all the documentation) would this meet the
>requirements?

The governance repository will be worded as such to permit a TA to be done
by the project team or a competent third party.  (The third party in this
case being the internal product TA that most companies already have in
place).  I think the TA would have to be made public however, such that we
can audit the threat analysis as a community.

Perhaps the security team needs a repository containing the threat
analysis documents for various projects to be published on docs.oo.

Does that solve your concerns?
>
>I ask, as Designate looks like it meets nearly  all the current
>requirements - the only outstanding question in my mind was the
>Threat Analysis
>
 [1]:
 
http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-
31-
 17.00.log.txt

 [2]:
 
http://governance.openstack.org/reference/tags/vulnerability_managed.ht
ml

 [3]: https://review.openstack.org/#/c/220712/

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


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

Re: [openstack-dev] [nova] the bugs team needs (more) members

[Adam Lawson]

Markus,

If you van connect me with someone who can tell me what needs the most
attention and how to get started, I'd be happy to help.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Apr 1, 2016 at 3:46 AM, Markus Zoeller  wrote:

> TL;DR: * The Nova bugs team needs more members
>* Tasks: https://wiki.openstack.org/wiki/BugTriage
>* Cleanup: http://45.55.105.55:8082/bugs-dashboard.html
>* Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
>* Etherpad: https://etherpad.openstack.org/p/nova-bugs-team
>
>
> The Nova project has a large backlog of open bug reports. Around 5 new
> bug reports get created everyday. It is not possible to make a
> reasonable progress with the current number of people. The nova bugs
> team needs to play a more active role and it needs more people for that.
>
>
> What's in for you?
> --
> As bugs are in every software in every place, you will get around a lot.
> Having a specific issue makes it also easier to ping other folks to
> discuss this issue. Bug fixes also don't have the hard deadlines
> imposed on feature patches. Being once on the bug triage side will
> improve the quality of your future bug reports which will make them
> more likely to get solved.
>
>
> Current Status
> --
> The main issue which slows down all following steps are bug reports
> without the essential informations [1]:
> * versions (nova, hypervisor, database, ...)
> * steps-to-reproduce (with actual data)
> * expected behavior
> * actual observed behavior
> * logs (in debug mode)
> * topology (for example: nova-network vs. neutron)
> Although this gets asked for when creating a bug report, the vast
> majority of bug reports lack this information. Usually it takes one
> to three roundtrips to get this information from the reporter. This
> is time consuming. As we focus less on new features in Newton [2] I
> have the hope that the bug list will get more attention.
>
>
> Tasks
> -
> The tasks are listed in the wiki [3]. They "just" need to be done.
> Repeatedly. Some on a daily basis, some less frequently. The cleanup
> dashboard [4] is a tool I use personally but can be used by you too.
>
> The Neutron folks introduced a weekly rotating bug skimming duty and
> they've made good experiences with it. This involves 1-3 people who
> check new bugs reports if they are valid and provide the essential
> information. We should adapt that [5].
>
> In general we should aim for:
> * respond to new bugs in a timely manner to get high quality reports
> * clean up the "old stuff" (>= 1.5 years)
> * spread the effort to multiple shoulders
> * rotate the different efforts to prevent exhaustion and tunnel vision
>
> There is an ongoing effort to move the RFEs (request for feature
> enhancements) away from the bug list [6] to allow us to be more
> focused on faulty behavior of existing features people already rely on.
>
>
> Organization
> 
> * The nova bugs team has an IRC meeting [7] which allows us to sync
>   with each other.
> * The cleanup dashboard [4] shows bug reports which need a check
>   based on the tasks [3].
> * The etherpad [8] can be used to avoid an overlap of efforts of
>   different people.
>
>
> Education
> -
> It's possible to use the nova bugs team IRC meeting for education
> sessions if this helps you.
> I will also attend the summit in Austin in a few weeks. We can do an
> unofficial "bugs mgmt process" crash course there if you like. Just
> talk to me there (or beforehand in IRC) and we will find the time
> and space.
> At last I can offer a Google Hangout session if some are interested
> in that.
>
>
> How to Join?
> 
> * Join the nova-bugs Launchpad group [9]
> * Familiarize with the process [10]
> * Attend the bugs meeting [7]
>
> With a few people who are willing to spent a few hours per week we
> can create a well maintained bug list where issues get addressed
> in a timely manner to consistently improve the quality of Nova.
>
>
> References
> --
> [1] "working on bug reports; what blocks you?":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089677.html
> [2] "No spec approvals for new things until after the summit":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html
> [3] https://wiki.openstack.org/wiki/BugTriage
> [4] http://45.55.105.55:8082/bugs-dashboard.html
> [5]
> https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
> [6] "Wishlist bugs == (trivial) blueprint?":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html
> [7] https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
> [8] https://etherpad.openstack.org/p/nova-bugs-team
> [9] https://launchpad.net/~nova-bugs
> [10] 

Re: [openstack-dev] [OpenStack-DefCore] [defcore][glance] Glare not defcore ready

[Nikhil Komawar]

Rochelle, thanks for replying. Glad to hear all the voices.

Response inline.

On 4/1/16 3:24 PM, Rochelle Grober wrote:
> Hi folks.
>
> I'm chiming in here from a systems engineering perspective.  I recently 
> discovered that OpenStack-client is trying to build cross-project consistency 
> into its design.  As such, it is opinionated, but this is good.  The glance 
> team might consider also consulting the OSC team to ensure api structure 
> compatibility with the OpenStack client.
>

+1 on consulting the OSC. I think the initiative is trying to capture as
much consistency across the OS ecosystem as feasible. So, definitely OSC
is a good & thus important pointer.

> Yeah, this is a lot to rollup, but the more consistency across projects, the 
> friendlier it is to deployers and users, so heading that way soonest, but 
> when/where it makes sense would be a *good thing*.
>

Makes sense on the applicability on the purist principles (in this case
consistency approach to the design).

I would to like to chat a bit more on the system engg. perspective as
well. I think there's a bit more to the design that consistency but all
the discussions will be quite subjective/abstract right now and
inappropriate for the ML discussions (possible cause of another set of
confusions).

If possible, let's all gather at the summit.

> --Rocky
>
>
> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
> Sent: Friday, April 01, 2016 10:38 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Mikhail Fedosin; defcore-commit...@lists.openstack.org; Flavio Percoco
> Subject: Re: [OpenStack-DefCore] [openstack-dev] [defcore][glance] Glare not 
> defcore ready
>
> Thank you for your emails Flavio and Mike. It's really good to get a
> clarity out there.
>
> Hence, yes, the intent of the DefCore meeting was to get more "clarity"
> on the entire situation and making sure that the project proceeds with
> compliant standards. However, meetings can be informal and if anyone
> perceived anything differently, I would like to apologize from my end.
> I'm happy to clarify more things. Please feel free to ping me, send me
> email or ask for chat if you do think that's necessary.
>
> One important thing that I wanted to clarify for Newton, our top
> priorities are 1) working with the Nova team for adoption of the Glance
> v2 API 2) moving ahead and fast on the import refactor work. All of
> these are strongly tied together API hardening and ensuring we support
> interoperability requirements.
>
> Looking forward to move collaboration with the DefCore committee in the
> future.
>
> On 4/1/16 1:03 PM, Mikhail Fedosin wrote:
>> Hi Flavio! Thank you for the clarification.
>>
>> I do realize that I missed both meetings and that logs from one of
>> them are not
>>
>> complete. I apologize if I've misinterpreted the intentions here.
>> I do think
>>
>> engaiging with DefCore as early in the process as possible is good
>> but I'd also
>>
>> like to clarify the intentions here before this escalates (again)
>> into more
>>
>> confusion about what Glance's future looks like.
>>
>>
>> I want to tell youthat the intention of the DefCore meeting was not to
>> confuse more on the work, rather it was to get clarity on all the
>> constraints that we are stuck with. Currently we intend to keep our
>> focus on interoperability issues this cycle - API hardening being our
>> first priority, along with early adoption from Murano and Community
>> App Catalog.
>>
>> And also I want to assure the community that Glare is being developed
>> consistent with the API WG principles and in such a way that it could
>> be included in DefCore at the appropriate time.
>>
>> Best regards,
>> Mikhail Fedosin
>>
>> On Fri, Apr 1, 2016 at 6:02 PM, Flavio Percoco > > wrote:
>>
>> Greetings,
>>
>>
>>
>> I missed yday's Glance meeting but I went ahead and read the logs.
>> While I was
>>
>> at it, I read a sentence from Erno (under the Glare updates topic)
>> that caught
>>
>> my eye:
>>
>>
>>
>> 14:06:27  About that. I got couple of pings last
>> night asking wtf is
>>
>> going on. Could we please stop selling Glare as
>> replacement for Glance at
>>
>> least until we have a) stable API and b) some level of
>> track record/testing
>>
>> that it actually is successfully working
>>
>>
>>
>> I went ahead and looked for the defcore meeting logs[0] (btw,
>> seems like the bot
>>
>> died during the meeting) to get a better understanding of what
>> Erno meant (I
>>
>> assumed the pings he mentioned came from the meeting and then
>> confirmed it).
>>
>>
>>
>> From the small piece of conversation I could read, and based on
>> the current
>>
>> status of development, priorities and support, I noticed a few
>> "issues" that I
>>
>> believe 

[openstack-dev] [nova][scheduler] Next Meeting: Monday, April 4 @ 1400UTC

[Edward Leafe]

The next meeting for the Nova Scheduler sub-team is scheduled for Monday, April 
4 at 1400 UTC.

http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160404T14

The agenda is at https://wiki.openstack.org/wiki/Meetings/NovaScheduler - feel 
free to add items that need to be discussed to that page.

I won't be able to make it, but Chris Dent has graciously volunteered to run 
the meeting. Be nice to him.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] Split k8s-client in separate python package

[Davanum Srinivas]

Team,

I've been meaning to do this for a while. Short version, see repo:
https://github.com/dims/python-k8sclient/

Long version:
- Started from the magnum repo.
- pulled out just ./magnum/common/pythonk8sclient
- preserved entire history in case we had to go back
- reorganized directory structure
- ran openstack cookie cutter and added generated files
- added a test that actually works against a live k8s :)
  
https://github.com/dims/python-k8sclient/blob/master/k8sclient/tests/test_k8sclient.py

Question:
- Should this be a new openstack/ repo?
- Would the Magnum team own the repo and use the new python package?

Thanks,
Dims


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

Re: [openstack-dev] [OpenStack-DefCore] [defcore][glance] Glare not defcore ready

[Rochelle Grober]

Hi folks.

I'm chiming in here from a systems engineering perspective.  I recently 
discovered that OpenStack-client is trying to build cross-project consistency 
into its design.  As such, it is opinionated, but this is good.  The glance 
team might consider also consulting the OSC team to ensure api structure 
compatibility with the OpenStack client.

Yeah, this is a lot to rollup, but the more consistency across projects, the 
friendlier it is to deployers and users, so heading that way soonest, but 
when/where it makes sense would be a *good thing*.

--Rocky


-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: Friday, April 01, 2016 10:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Mikhail Fedosin; defcore-commit...@lists.openstack.org; Flavio Percoco
Subject: Re: [OpenStack-DefCore] [openstack-dev] [defcore][glance] Glare not 
defcore ready

Thank you for your emails Flavio and Mike. It's really good to get a
clarity out there.

Hence, yes, the intent of the DefCore meeting was to get more "clarity"
on the entire situation and making sure that the project proceeds with
compliant standards. However, meetings can be informal and if anyone
perceived anything differently, I would like to apologize from my end.
I'm happy to clarify more things. Please feel free to ping me, send me
email or ask for chat if you do think that's necessary.

One important thing that I wanted to clarify for Newton, our top
priorities are 1) working with the Nova team for adoption of the Glance
v2 API 2) moving ahead and fast on the import refactor work. All of
these are strongly tied together API hardening and ensuring we support
interoperability requirements.

Looking forward to move collaboration with the DefCore committee in the
future.

On 4/1/16 1:03 PM, Mikhail Fedosin wrote:
> Hi Flavio! Thank you for the clarification.
>
> I do realize that I missed both meetings and that logs from one of
> them are not
>
> complete. I apologize if I've misinterpreted the intentions here.
> I do think
>
> engaiging with DefCore as early in the process as possible is good
> but I'd also
>
> like to clarify the intentions here before this escalates (again)
> into more
>
> confusion about what Glance's future looks like.
>
>
> I want to tell youthat the intention of the DefCore meeting was not to
> confuse more on the work, rather it was to get clarity on all the
> constraints that we are stuck with. Currently we intend to keep our
> focus on interoperability issues this cycle - API hardening being our
> first priority, along with early adoption from Murano and Community
> App Catalog.
>
> And also I want to assure the community that Glare is being developed
> consistent with the API WG principles and in such a way that it could
> be included in DefCore at the appropriate time.
>
> Best regards,
> Mikhail Fedosin
>
> On Fri, Apr 1, 2016 at 6:02 PM, Flavio Percoco  > wrote:
>
> Greetings,
>
>
>
> I missed yday's Glance meeting but I went ahead and read the logs.
> While I was
>
> at it, I read a sentence from Erno (under the Glare updates topic)
> that caught
>
> my eye:
>
>
>
> 14:06:27  About that. I got couple of pings last
> night asking wtf is
>
> going on. Could we please stop selling Glare as
> replacement for Glance at
>
> least until we have a) stable API and b) some level of
> track record/testing
>
> that it actually is successfully working
>
>
>
> I went ahead and looked for the defcore meeting logs[0] (btw,
> seems like the bot
>
> died during the meeting) to get a better understanding of what
> Erno meant (I
>
> assumed the pings he mentioned came from the meeting and then
> confirmed it).
>
>
>
> From the small piece of conversation I could read, and based on
> the current
>
> status of development, priorities and support, I noticed a few
> "issues" that I
>
> believe are worth raising:
>
>
>
> 1. Glare's API is under discussion and it's a complementary
> service for Glance.
>
> [1] 2. Glare should not be a required API for every cloud, whereas
> Glance is and
>
> it should be kept that way for now. 3. Glare is not a drop-in
> replacement for
>
> Glance and it'll need way more discussions before that can happen.
>
>
>
> I do realize that I missed both meetings and that logs from one of
> them are not
>
> complete. I apologize if I've misinterpreted the intentions here.
> I do think
>
> engaiging with DefCore as early in the process as possible is good
> but I'd also
>
> like to clarify the intentions here before this escalates (again)
> into more
>
> confusion about what Glance's future looks like.
>
>
>
> So, to summarize, I don't think Glare should be added in DefCore
> in the near
>
> 

[openstack-dev] [monasca][release] missing build artifacts

[Doug Hellmann]

Monasca team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to
the build artifacts for monasca-ceilometer, monasca-log-api, and
monasca-thresh point to missing files. These repositories either
don't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml or don't have tox.ini
set up correctly (or both), so it's not clear how tagging is producing
a release for you.

For now, we are disabling links to the artifacts for those repos
via https://review.openstack.org/300457 but we're also planning to
remove them from the official Mitaka page since there don't
appear to be any actual related deliverables
(https://review.openstack.org/300619).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?

Thanks,
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] [neutron]: Neutron naming legal issues

[Stephen Wong]

Wait... is this April's Fool?

(hard to believe project name change resulting from name clashing with a
Marvel comic character)

On Fri, Apr 1, 2016 at 11:57 AM, Carl Baldwin  wrote:

> On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka 
> wrote:
> > We could play words, like Quantron or Neutrum. Actually, it makes perfect
> > sense to me, since the change to rename all project name references will
> be
> > half the size of the proposed solution, and may even save us some git
> > conflicts, assuming we hack Gerrit to use word-based conflict merging
> > engine.
>
> Quantron!  I like it.  :)
>
> Carl
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [murano][release] missing build artifacts

[Doug Hellmann]

Murano team,

We noticed in our audit of the links on
http://releases.openstack.org/mitaka/index.html that the links to the
build artifacts for murano-apps point to missing files. The murano-apps
repository doesn't seem to have any real build jobs configured in
openstack-infra/project-config/zuul/layout.yaml, so it's not clear how
tagging is producing a release for you.

For now, we are disabling links to the artifacts for that repo via
https://review.openstack.org/300457 but we're also planning to remove
murano-apps from the official Mitaka page since there don't appear to be
any actual related deliverables (https://review.openstack.org/300473).

It would be good to understand what your intent is for builds. Can
you follow up here on this thread with some details?

Thanks,
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-dev] Acknowledging Jim Blair's work on the TC

[Anita Kuno]

Jim is an incumbent on the TC this election and he didn't run. I'm
posting this to express my thanks to Jim for his work and dedication on
the TC.

Jim, I think your commitment to open source, spanning many years before
OpenStack, and your dedication to governance process, are qualities I
admire very much and I'm grateful you were able to voice your opinions
on the TC from October 2013 until now.

Thank you for taking your turn and thank you as well for allowing others
a chance to take theirs.

Thank you, Jim,
Anita.

__
OpenStack Development Mailing 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] Adding amuller to the neutron-drivers team

[Carl Baldwin]

Welcome, Assaf!

On Thu, Mar 31, 2016 at 6:48 PM, Armando M.  wrote:
> Hi folks,
>
> Assaf's tenacity is a great asset for the Neutron team at large. I believe
> that the drivers team would benefit from that tenacity, and therefore I
> would like to announce him to be a new member of the Neutron Drivers team
> [1].
>
> At the same time, I would like to thanks mestery as he steps down. Mestery
> has been instrumental in many decisions taken by this team and for
> spearheading the creation of the very team back in the Juno days.
>
> As I mentioned in the past, having a propension to attendance, and desire to
> review of RFEs puts you on the right foot to join the group, whose members
> are rotated regularly so that everyone is given the opportunity to grow, and
> no-one burns out.
>
> The team [1] meets regularly on Thursdays [2], and anyone is welcome to
> attend.
>
> Please, join me in welcome Assaf to the team.
>
> Cheers,
> Armando
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>
> __
> OpenStack Development Mailing 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] Floating IPs and Public IPs are not equivalent

[Matt Kassawara]

Sean,

I can tell you how the configuration should work. Sean Collins and I have
collaborated quite a bit on how to fix the DevStack networking problems...
mostly by replacing the legacy neutron bits with something a bit more
flexible and less crufty.

On Fri, Apr 1, 2016 at 12:39 PM, Monty Taylor  wrote:

> On 04/01/2016 12:00 PM, Fox, Kevin M wrote:
>
>> And with external rbac in mitaka, you can finally have private floating
>> ip's. :)
>>
>
> Wha. I mean.
>
> My face. It just fell off.
>
> 
>> *From:* Monty Taylor
>> *Sent:* Thursday, March 31, 2016 10:23:22 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] Floating IPs and Public IPs are not equivalent
>>
>>
>> Just a friendly reminder to everyone - floating IPs are not synonymous
>> with Public IPs in OpenStack.
>>
>> The most common (and growing, thank you to the beta of the new
>> Dreamcompute cloud) configuration for Public Clouds is directly assign
>> public IPs to VMs without requiring a user to create a floating IP.
>>
>> I have heard that the require-floating-ip model is very common for
>> private clouds. While I find that even stranger, as the need to run NAT
>> inside of another NAT is bizarre, it is what it is.
>>
>> Both models are common enough that pretty much anything that wants to
>> consume OpenStack VMs needs to account for both possibilities.
>>
>> It would be really great if we could get the default config in devstack
>> to be to have a shared direct-attached network that can also have a
>> router attached to it and provider floating ips, since that scenario
>> actually allows interacting with both models (and is actually the most
>> common config across the OpenStack public clouds)
>>
>> Monty
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron]: Neutron naming legal issues

[Carl Baldwin]

On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka  wrote:
> We could play words, like Quantron or Neutrum. Actually, it makes perfect
> sense to me, since the change to rename all project name references will be
> half the size of the proposed solution, and may even save us some git
> conflicts, assuming we hack Gerrit to use word-based conflict merging
> engine.

Quantron!  I like it.  :)

Carl

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

[openstack-dev] [Fuel] Newton Design Summit sessions planning

[Vladimir Kozhukalov]

Dear colleagues,

Looks like we have final version sessions layout [1]
for Austin design summit. We have 3 fishbows,
11 workrooms, full day meetup.

Here you can find some useful information about design
summit [2]. All session leads must read this page,
be prepared for their sessions (agenda, slides if needed,
etherpads for collaborative work, etc.) and follow
the recommendations given in "At the Design Summit" section.

Here is Fuel session planning etherpad [3]. Almost all suggested
topics have been put there. Please put links to slide decks
and etherpads next to respective sessions. Here is the
page [4] where other teams publish their planning pads.

If session leads want for some reason to swap their slots it must
be requested in this ML thread. If for some reason session lead
can not lead his/her session, it must be announced in this ML thread.

Fuel sessions are:
===
Fishbowls:
===
Wed:
15:30-16:10
16:30:17:10
17:20-18:00

===
Workrooms:
===
Wed:
9:00-9:40
9:50-10:30
11:00-11:40
11:50-12:30
13:50-14:30
14:40-15:20
Thu:
9:00-9:40
9:50-10:30
11:00-11:40
11:50-12:30
13:30-14:10

===
Meetup:
===
Fri:
9:00-12:30
14:00-17:30

[1]
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/d59d38b7/attachment.pdf
[2] https://wiki.openstack.org/wiki/Design_Summit
[3] https://etherpad.openstack.org/p/fuel-newton-summit-planning
[4] https://wiki.openstack.org/wiki/Design_Summit/Planning

Thanks.

Vladimir Kozhukalov
__
OpenStack Development Mailing 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] Floating IPs and Public IPs are not equivalent

[Monty Taylor]

On 04/01/2016 12:00 PM, Fox, Kevin M wrote:

And with external rbac in mitaka, you can finally have private floating
ip's. :)


Wha. I mean.

My face. It just fell off.



*From:* Monty Taylor
*Sent:* Thursday, March 31, 2016 10:23:22 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* [openstack-dev] Floating IPs and Public IPs are not equivalent

Just a friendly reminder to everyone - floating IPs are not synonymous
with Public IPs in OpenStack.

The most common (and growing, thank you to the beta of the new
Dreamcompute cloud) configuration for Public Clouds is directly assign
public IPs to VMs without requiring a user to create a floating IP.

I have heard that the require-floating-ip model is very common for
private clouds. While I find that even stranger, as the need to run NAT
inside of another NAT is bizarre, it is what it is.

Both models are common enough that pretty much anything that wants to
consume OpenStack VMs needs to account for both possibilities.

It would be really great if we could get the default config in devstack
to be to have a shared direct-attached network that can also have a
router attached to it and provider floating ips, since that scenario
actually allows interacting with both models (and is actually the most
common config across the OpenStack public clouds)

Monty

__
OpenStack Development Mailing 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Matt Kassawara]

Hi,

I didn't see this e-mail until now because I'm busy trying to update and
test the installation guide in time for the Mitaka release. As a primary
contributor to the installation guide for about six releases including
restructuring it a couple of times, I think I can explain why we do what we
do.

First, a little history about the guide...

The installation guide often provides the first experience for people
trying OpenStack. Thus, the guide should provide not just a good
experience, but a great experience. We can all agree on wanting more
adoption of OpenStack. For many people, launching an instance and being
able to access it feels like summiting a mountain. My first experience with
OpenStack involved nearly a month of trying to install Grizzly with neutron
for evaluation purposes using the installation guide. It didn't work.
Looking at various support channels such as IRC and ask.openstack.org, most
people were stuck at the same place without any answers. I finally
determined that nova lacked the configuration telling it to use neutron for
networking, so it kept attempting to build nova networks when those
components didn't exist. I opened a bug and someone fixed it. Shortly
thereafter, I began addressing the seemingly infinite number of
installation guide bugs. However, the cycle of frustration was beginning to
repeat itself with Havana. The reactive method of finding a problem,
opening a bug, and waiting for a patch simply wasn't working for our
audience of potential operators, not developers, that just expect it to
work.

So, I proposed changing the guide from reactive to proactive. In other
words, we update and test the guide prior to release for every distribution
it supports. We began this approach with Icehouse and saw a decrease in
bugs and frustration. Furthermore, when assisting people through various
support channels, we could more easily determine whether the problem was a
just a typo or a problem with the guide. However, proactively maintaining
the guide put a significant burden on the contributors. Gone were the days
of "fire-and-forget" patches. Almost all patches require actual testing,
sometimes across several distributions. Updating the guide for the next
release requires performing full installations, often several times per
distribution, until we can successfully install and test all services
without deviating from the instructions. A considerable amount of work,
especially about a month before release when contributors who involve
themselves in other projects are also busy trying to release those
projects. Thus, the installation guide has seen a decrease in contributions
making it increasingly difficult to update and test for each release.
Furthermore, the installation guide receives little, if any, support from
most projects including "core" projects. Even if those projects know about
the installation guide, most assume that the documentation team magically
updates it for every release to deploy each service in a basic fashion
accounting for configuration changes and recommendations. From the
perspective of a project developer, those updates probably seem simple.
Just read the code, track patches, and maybe attend some meetings, right?
>From the perspective of installation guide contributors, we can't involve
ourselves that deeply in one project let alone nearly ten projects. Imagine
us trying to consider big tent projects? We have begged projects for years
to provide resources for maintaining the installation guide. If nothing
else, provide some notes on an etherpad indicating what we should change.
At this point in the game, we shouldn't have to resort to deprecation
messages or gate job configurations to determine how to deploy a service.

Regarding use of distribution packages instead of source...

The guide uses distribution packages instead of source because our audience
is usually familiar with them and they eliminate a significant number of
steps in an already complex and often overwhelming process. For example,
packages manage dependencies and provide init scripts. The installation
guide teaches our audience how to deploy the most common OpenStack services
for evaluation purposes. For example, our audience quickly learns that each
service typically depends on keystone, a database, and a message queue.
After getting comfortable with the installation process, we recommend
implementing redundancy/security on top of a basic installation and
eventually tooling for a production deployment.

Distribution packages aren't perfect by any means. First, they usually lag
the upstream release cycle by several weeks which forces us to update and
test changes using milestones, sometimes not even the last "feature-freeze"
milestone, after the first release candidate appears upstream. Next, they
sometimes contain bugs and packagers seldom contribute resources to triage
and address them which forces us to implement workarounds that can confuse
or distract our audience. Finally, and 

[openstack-dev] [release][requirements] global requirements master branch is unfrozen

[Doug Hellmann]

Folks,

The global requirements repo (openstack/requirements) is now open for
Newton-related changes. I've removed the -2 votes from all of the
patches I froze, but there may be some from other reviewers. Please
contact them directly if your patch still has a procedural block, but
keep in mind that during the week right before the release they may not
have time to do more than remove their -2.

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] [docs] [api] Oh Swagger, where art thou?

[Jim Rollenhagen]

On Fri, Apr 01, 2016 at 10:13:49AM -0500, Anne Gentle wrote:
> On Thu, Mar 31, 2016 at 11:22 AM, Jim Rollenhagen 
> wrote:
> 
> > On Thu, Mar 31, 2016 at 09:50:48AM -0400, Sean Dague wrote:
> > > On 03/31/2016 09:43 AM, Jim Rollenhagen wrote:
> > > > On Thu, Mar 31, 2016 at 08:43:29AM -0400, Sean Dague wrote:
> > > >> Some more details on progress, because this is getting closer every
> > day.
> > > >>
> > > >> There is now an api-ref target on the Nova project. The entire work in
> > > >> progress stream has been rebased into 2 patches to a top level
> > api-ref/
> > > >> directory structure in the Nova tree -
> > > >>
> > https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:wip_api_docs2
> > > >>
> > > >> That is a 2 patch series. The first is the infrastructure, the second
> > is
> > > >> the content for 2 resources (versions and servers). The rendered
> > output
> > > >> for this is at -
> > > >>
> > http://docs-draft.openstack.org/63/298763/4/check/gate-nova-api-ref/6983838//api-ref/build/html/
> > > >> (you can also pull and build locally with tox -e api-ref)
> > > >>
> > > >> Karen, Auggy, and Anne continue to work on the wadl data translator
> > > >> using the wadl2rst project and fairy-slipper to get various pieces of
> > > >> the structured data over. Hopefully we'll see some of those translated
> > > >> stacks rendering soon in patch sets.
> > > >
> > > > I assume at some point we'll be pulling the sphinx extension out to a
> > > > separate project so that other projects can use this too? :)
> > > >
> > > > // jim
> > >
> > > Yes. I feel like it's probably a milestone 2 activity. Fixing styling
> > > and error handling is a lot faster in tree while we sort out all the
> > > issues. Once it's good we can move things into something that's pip
> > > installable.
> >
> > Sounds good, thanks for pushing on this. Looking forward to using it in
> > ironic. :)
> 
> 
> Hi Jim,
> A tidbit just for ironic, please review
> https://review.openstack.org/#/c/245459 and then we can use that content to
> migrate over with the tooling we're creating now. With a good technical
> review now your content will be in good shape.
> Thanks,
> Anne

Fantastic! Nobody told me this was in progress. Thanks Anne!

// jim

> 
> 
> >
> > // jim
> >
> > >
> > >   -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
> >
> 
> 
> 
> -- 
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com

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


__
OpenStack Development Mailing 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] Searching with the Summit Schdule App

[Anita Kuno]

My preference when consuming the schedule for the Design Summit is to
see an entire project track in one view. I was unable to figure out how
to accomplish this by clicking things on
https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-27_types=2
(the link ttx had provided for the design summit in the -dev channel).

I filed this bug: https://bugs.launchpad.net/openstack-org/+bug/1565018
and then learned from fungi who was relaying a message from one of the
web developers for the app that if you search on : that
this returns the events for that project's track in the Design Summit,
not the Conference or anything else.

Remove that colon (:) and you get every hit for the project name in your
results.

It sounds like the web team is working on making this discoverable for
Barcelona so I thought more folks than just me would like to know about
this for Austin. (That and save the web team from having to explain it
over and over.)

Thank you,
Anita.


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

Re: [openstack-dev] [nova] Which SSL ca_file does a person use, really?

[Jim Rollenhagen]

On Fri, Apr 01, 2016 at 11:07:40AM -0500, Matt Riedemann wrote:
> We have a lot of CA file options in nova:
> 
> 1. DEFAULT.ca_file - this is used in nova.crypto
> 2. ssl.ca_file - this is used when constructing glanceclient
> 3. DEFAULT.ssl_ca_file - this is used in nova.wsgi
> 4. vmware.ca_file - for connecting to vcenter
> 5. neutron.cafile - for constructing neutronclient
> 6. cinder.cafile - for constructing cinderclient
> 7. keystone_authtoken.cafile - for constructing keystoneauth
> 8. barbican.cafile - for constructing barbicanclient

+ ironic.cafile - for constructing ironicclient.
https://github.com/openstack/nova/commit/0230edd708eb961ad6f9afb88a778fe03320bf3e

> 
> As far as I can see none of these are deprecated. The keystone_auth one is
> probably coming from one of the keystone library options, so we can't do
> much about that.
> 
> But it seems like the first three, and then the other ones for connecting to
> neutron/cinder/barbican clients could all be collapsed, or is that not the
> intent?

I think in most cases they could, and I don't think anybody is going to
say it shouldn't be in this email.

However, I'd be willing to bet there's some cloud out there where at
least one of these services is owned by a separate team than Nova, who
uses a different CA than the rest of things.

// jim

> 
> I remember Matthew Gilliard working on something related to this at one
> point where we were going to use a DictOpt where the default value comes
> from ssl.ca_file (which is defined in oslo.service) but you could override
> that for specific functions, like if you want different files for connecting
> to the different clients.
> 
> Is anyone else working on something like this because it's super confusing
> for deployers.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

[Nikhil Komawar]

Excellent!

Thank you, Christopher, for supplementing by sharing the logs and the
perspective.

On 4/1/16 1:10 PM, Christopher Aedo wrote:
> On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco  wrote:
>> Greetings,
>>
>> I missed yday's Glance meeting but I went ahead and read the logs. While I
>> was
>> at it, I read a sentence from Erno (under the Glare updates topic) that
>> caught
>> my eye:
>>
>> 14:06:27  About that. I got couple of pings last night
>> asking wtf is
>> going on. Could we please stop selling Glare as replacement for
>> Glance at
>> least until we have a) stable API and b) some level of track
>> record/testing
>> that it actually is successfully working
>>
>> I went ahead and looked for the defcore meeting logs[0] (btw, seems like the
>> bot
>> died during the meeting) to get a better understanding of what Erno meant (I
>> assumed the pings he mentioned came from the meeting and then confirmed it).
>>
>> From the small piece of conversation I could read, and based on the current
>> status of development, priorities and support, I noticed a few "issues" that
>> I
>> believe are worth raising:
>>
>> 1. Glare's API is under discussion and it's a complementary service for
>> Glance.
>> [1] 2. Glare should not be a required API for every cloud, whereas Glance is
>> and
>> it should be kept that way for now. 3. Glare is not a drop-in replacement
>> for
>> Glance and it'll need way more discussions before that can happen.
>>
>> I do realize that I missed both meetings and that logs from one of them are
>> not
>> complete. I apologize if I've misinterpreted the intentions here. I do think
>> engaiging with DefCore as early in the process as possible is good but I'd
>> also
>> like to clarify the intentions here before this escalates (again) into more
>> confusion about what Glance's future looks like.
>>
>> So, to summarize, I don't think Glare should be added in DefCore in the near
>> future. The Glance team should focus on fixing the current interoperability
>> issues before we'll be able to actually try to build on top of the current
>> API.
> I was just about to type a response to this but saw Mikhail already
> responded.  As he said the team was seeking guidance and wanted to be
> sure they were proceeding in the right direction long term, not
> pushing for an immediate inclusion.
>
> I've shared my logs from the meeting here[1] which are complete, so
> you can see the conversation in it's entirety.
>
> [1]: http://paste.openstack.org/show/492753/
>
> -Christopher
>
>
>> Hope the above makes sense,
>> Flavio
>>
>> [0]
>> http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
>> [1] https://review.openstack.org/#/c/283136
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 

Thanks,
Nikhil



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

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

[Nikhil Komawar]

Thank you for your emails Flavio and Mike. It's really good to get a
clarity out there.

Hence, yes, the intent of the DefCore meeting was to get more "clarity"
on the entire situation and making sure that the project proceeds with
compliant standards. However, meetings can be informal and if anyone
perceived anything differently, I would like to apologize from my end.
I'm happy to clarify more things. Please feel free to ping me, send me
email or ask for chat if you do think that's necessary.

One important thing that I wanted to clarify for Newton, our top
priorities are 1) working with the Nova team for adoption of the Glance
v2 API 2) moving ahead and fast on the import refactor work. All of
these are strongly tied together API hardening and ensuring we support
interoperability requirements.

Looking forward to move collaboration with the DefCore committee in the
future.

On 4/1/16 1:03 PM, Mikhail Fedosin wrote:
> Hi Flavio! Thank you for the clarification.
>
> I do realize that I missed both meetings and that logs from one of
> them are not
>
> complete. I apologize if I've misinterpreted the intentions here.
> I do think
>
> engaiging with DefCore as early in the process as possible is good
> but I'd also
>
> like to clarify the intentions here before this escalates (again)
> into more
>
> confusion about what Glance's future looks like.
>
>
> I want to tell youthat the intention of the DefCore meeting was not to
> confuse more on the work, rather it was to get clarity on all the
> constraints that we are stuck with. Currently we intend to keep our
> focus on interoperability issues this cycle - API hardening being our
> first priority, along with early adoption from Murano and Community
> App Catalog.
>
> And also I want to assure the community that Glare is being developed
> consistent with the API WG principles and in such a way that it could
> be included in DefCore at the appropriate time.
>
> Best regards,
> Mikhail Fedosin
>
> On Fri, Apr 1, 2016 at 6:02 PM, Flavio Percoco  > wrote:
>
> Greetings,
>
>
>
> I missed yday's Glance meeting but I went ahead and read the logs.
> While I was
>
> at it, I read a sentence from Erno (under the Glare updates topic)
> that caught
>
> my eye:
>
>
>
> 14:06:27  About that. I got couple of pings last
> night asking wtf is
>
> going on. Could we please stop selling Glare as
> replacement for Glance at
>
> least until we have a) stable API and b) some level of
> track record/testing
>
> that it actually is successfully working
>
>
>
> I went ahead and looked for the defcore meeting logs[0] (btw,
> seems like the bot
>
> died during the meeting) to get a better understanding of what
> Erno meant (I
>
> assumed the pings he mentioned came from the meeting and then
> confirmed it).
>
>
>
> From the small piece of conversation I could read, and based on
> the current
>
> status of development, priorities and support, I noticed a few
> "issues" that I
>
> believe are worth raising:
>
>
>
> 1. Glare's API is under discussion and it's a complementary
> service for Glance.
>
> [1] 2. Glare should not be a required API for every cloud, whereas
> Glance is and
>
> it should be kept that way for now. 3. Glare is not a drop-in
> replacement for
>
> Glance and it'll need way more discussions before that can happen.
>
>
>
> I do realize that I missed both meetings and that logs from one of
> them are not
>
> complete. I apologize if I've misinterpreted the intentions here.
> I do think
>
> engaiging with DefCore as early in the process as possible is good
> but I'd also
>
> like to clarify the intentions here before this escalates (again)
> into more
>
> confusion about what Glance's future looks like.
>
>
>
> So, to summarize, I don't think Glare should be added in DefCore
> in the near
>
> future. The Glance team should focus on fixing the current
> interoperability
>
> issues before we'll be able to actually try to build on top of the
> current API.
>
>
>
> Hope the above makes sense,
>
> Flavio
>
>
>
> [0]
> 
> http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
>
> [1] https://review.openstack.org/#/c/283136
>
>
>
> -- 
>
> @flaper87
>
> Flavio Percoco
>
>
> __
>
> OpenStack Development Mailing 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] Newton Summit: cross-project session for deployment tools projects

[Andrew Woodward]

An obvious +1 from me as well

On Fri, Apr 1, 2016 at 10:25 AM Paul Belanger  wrote:

> On Thu, Mar 31, 2016 at 05:40:53PM -0400, Emilien Macchi wrote:
> > Hi,
> >
> > OpenStack big tent has different projects for deployments: Puppet,
> > Chef, Ansible, Kolla, TripleO, (...) but we still have some topics  in
> > common.
> > I propose we use the Cross-project day to meet and talk about our
> > common topics: CI, doc, release, backward compatibility management,
> > etc.
> >
> > Feel free to look at the proposed session and comment:
> > https://etherpad.openstack.org/p/newton-cross-project-sessions
> >
> > Thanks,
> > --
> > Emilien Macchi
> I'm intereted in this too!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

[Flavio Percoco]

On 01/04/16 20:03 +0300, Mikhail Fedosin wrote:

Hi Flavio! Thank you for the clarification.


   I do realize that I missed both meetings and that logs from one of them are
   not
   complete. I apologize if I've misinterpreted the intentions here. I do
   think
   engaiging with DefCore as early in the process as possible is good but I'd
   also
   like to clarify the intentions here before this escalates (again) into more
   confusion about what Glance's future looks like.


I want to tell you that the intention of the DefCore meeting was not to confuse
more on the work, rather it was to get clarity on all the constraints that we
are stuck with. Currently we intend to keep our focus on interoperability
issues this cycle - API hardening being our first priority, along with early
adoption from Murano and Community App Catalog.

And also I want to assure the community that Glare is being developed
consistent with the API WG principles and in such a way that it could be
included in DefCore at the appropriate time.


Awesome!

I think reaching out to Defcore is the right thing to do. Glad that was the
intention and that we're on the same page.

Thanks for clarifying, Mike!
Flavio


Best regards,
Mikhail Fedosin

On Fri, Apr 1, 2016 at 6:02 PM, Flavio Percoco  wrote:

   Greetings,

   I missed yday's Glance meeting but I went ahead and read the logs. While I
   was
   at it, I read a sentence from Erno (under the Glare updates topic) that
   caught
   my eye:

           14:06:27  About that. I got couple of pings last night
   asking wtf is
           going on. Could we please stop selling Glare as replacement for
   Glance at
           least until we have a) stable API and b) some level of track record
   /testing
           that it actually is successfully working

   I went ahead and looked for the defcore meeting logs[0] (btw, seems like
   the bot
   died during the meeting) to get a better understanding of what Erno meant
   (I
   assumed the pings he mentioned came from the meeting and then confirmed
   it).

   From the small piece of conversation I could read, and based on the current
   status of development, priorities and support, I noticed a few "issues"
   that I
   believe are worth raising:

   1. Glare's API is under discussion and it's a complementary service for
   Glance.
   [1] 2. Glare should not be a required API for every cloud, whereas Glance
   is and
   it should be kept that way for now. 3. Glare is not a drop-in replacement
   for
   Glance and it'll need way more discussions before that can happen.

   I do realize that I missed both meetings and that logs from one of them are
   not
   complete. I apologize if I've misinterpreted the intentions here. I do
   think
   engaiging with DefCore as early in the process as possible is good but I'd
   also
   like to clarify the intentions here before this escalates (again) into more
   confusion about what Glance's future looks like.

   So, to summarize, I don't think Glare should be added in DefCore in the
   near
   future. The Glance team should focus on fixing the current interoperability
   issues before we'll be able to actually try to build on top of the current
   API.

   Hope the above makes sense,
   Flavio

   [0] http://eavesdrop.openstack.org/meetings/defcore/2016/
   defcore.2016-03-30-16.00.log.txt
   [1] https://review.openstack.org/#/c/283136

   --
   @flaper87
   Flavio Percoco
  
   __

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





--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

[Flavio Percoco]

On 01/04/16 10:10 -0700, Christopher Aedo wrote:

On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco  wrote:

Greetings,

I missed yday's Glance meeting but I went ahead and read the logs. While I
was
at it, I read a sentence from Erno (under the Glare updates topic) that
caught
my eye:

14:06:27  About that. I got couple of pings last night
asking wtf is
going on. Could we please stop selling Glare as replacement for
Glance at
least until we have a) stable API and b) some level of track
record/testing
that it actually is successfully working

I went ahead and looked for the defcore meeting logs[0] (btw, seems like the
bot
died during the meeting) to get a better understanding of what Erno meant (I
assumed the pings he mentioned came from the meeting and then confirmed it).

From the small piece of conversation I could read, and based on the current
status of development, priorities and support, I noticed a few "issues" that
I
believe are worth raising:

1. Glare's API is under discussion and it's a complementary service for
Glance.
[1] 2. Glare should not be a required API for every cloud, whereas Glance is
and
it should be kept that way for now. 3. Glare is not a drop-in replacement
for
Glance and it'll need way more discussions before that can happen.

I do realize that I missed both meetings and that logs from one of them are
not
complete. I apologize if I've misinterpreted the intentions here. I do think
engaiging with DefCore as early in the process as possible is good but I'd
also
like to clarify the intentions here before this escalates (again) into more
confusion about what Glance's future looks like.

So, to summarize, I don't think Glare should be added in DefCore in the near
future. The Glance team should focus on fixing the current interoperability
issues before we'll be able to actually try to build on top of the current
API.


I was just about to type a response to this but saw Mikhail already
responded.  As he said the team was seeking guidance and wanted to be
sure they were proceeding in the right direction long term, not
pushing for an immediate inclusion.

I've shared my logs from the meeting here[1] which are complete, so
you can see the conversation in it's entirety.



Thanks for clarifying and the logs! This is helpful!

Flavio


[1]: http://paste.openstack.org/show/492753/

-Christopher



Hope the above makes sense,
Flavio

[0]
http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
[1] https://review.openstack.org/#/c/283136

--
@flaper87
Flavio Percoco

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



--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all] Newton Summit: cross-project session for deployment tools projects

[Paul Belanger]

On Thu, Mar 31, 2016 at 05:40:53PM -0400, Emilien Macchi wrote:
> Hi,
> 
> OpenStack big tent has different projects for deployments: Puppet,
> Chef, Ansible, Kolla, TripleO, (...) but we still have some topics  in
> common.
> I propose we use the Cross-project day to meet and talk about our
> common topics: CI, doc, release, backward compatibility management,
> etc.
> 
> Feel free to look at the proposed session and comment:
> https://etherpad.openstack.org/p/newton-cross-project-sessions
> 
> Thanks,
> -- 
> Emilien Macchi
I'm intereted in this too!

__
OpenStack Development Mailing 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][library] Update of astute.yaml fixtures and noop tests

[Vladimir Kuklin]

Hi Alex

+1 to your proposal - this is long-awaited change.

On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko 
wrote:

> One more thing about spec to fixture mapping [0]. What if instead of:
>
> # RUN: (hiera1) (facts1)
>
> we'll use
>
> # RUN: (roles_array1) (facts1)
>
> ?
>
> We don't need to duplicate complicated task graph calculations to
> understand which task to execute, because we don't care about tasks
> ordering and dependencies in noop tests. All we need is to map rspec task
> tests to astute.yaml fixtures. And it could be done via roles.
>
> Regards,
> Alex
>
> [0]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>
>
> On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko 
> wrote:
>
>> Hi.
>>
>>   As you may know, we're still using some very old astute.yaml fixtures
>> (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have
>> problems with fixture-to-rspec mapping [1]. So we've started to work on
>> those problems [2].
>>
>>   So please be aware of upcoming changes in noop rspec fixtures and
>> tests. If you see, that some important fixtures are missing (thus not
>> covered by tests) please let me know in this email thread or via
>> IRC/email/slack.
>>
>>   Also, we should stop updating astute.yaml fixtures manually and start
>> using some kind of automation approach instead [3][4]. I propose to use [5]
>> script until we find a better solution. So if you want to add some new
>> astute.yaml fixture for noop tests, please propose a patch to this script
>> instead of uploading yaml file.
>>
>> Currently the following is missing in the new set of fixtures for
>> fuel-9.0:
>> - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
>> properly enable it via nailgun, any help is much appreciated)
>> - selective ssl fixtures - since configuration data is not serialized
>> from nailgun, I think that we should move this into 'hiera/override' along
>> with implementation of new hiera overrides tests workflow [6]
>> - vmware related fixtures
>>
>> Please feel free to share your ideas/comments on this topic.
>>
>> Thanks,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1535339
>> [1]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>> [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
>> [3]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
>> [4]
>> https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
>> [5]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
>> [6] https://bugs.launchpad.net/fuel/+bug/1564919
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

[Fox, Kevin M]

Params have the added advantage that horizon could be potentially tweaked to do 
form validation in the ui based in it.

Thanks,
Kevin


From: Steven Hardy
Sent: Friday, April 01, 2016 9:31:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote:
> On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter  wrote:
> > On 31/03/16 18:10, Zane Bitter wrote:
> >>
> >>
> >> I'm in favour of some sort of variable-based implementation for a few
> >> reasons. One is that (5) seems to come up fairly regularly in a complex
> >> deployment like TripleO. Another is that Fn::If feels awkward compared
> >> to get_variable.
> >
> >
> > I actually have to revise this last part after reviewing the patches.
> > get_variable can't replace Fn::If, because we'd still need to handle stuff
> > of the form:
> >
> > some_property: {if: [{get_variable: some_var},
> >  {get_resource: res1},
> >  {get_resource: res2}]
> >
> > where the alternatives can't come from a variable because they contain
> > resource references and we have said we'd constrain variables to be static.
> >
> > In fact the intrinsic functions that could be allowed in the first argument
> > to the {if: } function would have to constrained in the same way as the
> > constraint field in the resource, because we should only validate and obtain
> > dependencies from _one_ of the alternates, so we need to be able to
> > determine which one statically and not have to wait until the actual value
> > is resolved. This is possibly the strongest argument for keeping on the cfn
> > implementation course.
>
> We talked about another possibilities on IRC: instead of having a new
> section, create a new resource OS::Heat::Value which can hold some
> data. It would look like that:
>
> resources:
> is_prod:
> type: OS::Heat::Value
> properties:
> value: {equals: {get_param, env}, prod}}
>
> my_resource:
> condition: {get_attr: [is_prod, value}}

Another alternative (which maybe you discussed, sorry I missed the IRC
chat) would be just to use parameters, as that's already conceptually where
we obtain values that are input to resources.

E.g:

parameters:
  env:
   type: string
   default: prod

  is_prod:
type: boolean
default: {equals: {get_param, env}}

From an interface standpoint this seems much cleaner and more intuitive than
the other solutions discussed IMHO, but I suspect it's potentially harder to
implement.

Your original example gets much cleaner too if we allow all intrinsic function
(except get_attr) in the scope of parameters:

parameters:
  host:
type: string
  port:
type: string
  endpoint:
type: string
default:
  str_replace:
template:
   http://HOSTORT/
params:
   HOST: {get_param: host}
   PORT: {get_param: port}

Steve

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

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

[Christopher Aedo]

On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco  wrote:
> Greetings,
>
> I missed yday's Glance meeting but I went ahead and read the logs. While I
> was
> at it, I read a sentence from Erno (under the Glare updates topic) that
> caught
> my eye:
>
> 14:06:27  About that. I got couple of pings last night
> asking wtf is
> going on. Could we please stop selling Glare as replacement for
> Glance at
> least until we have a) stable API and b) some level of track
> record/testing
> that it actually is successfully working
>
> I went ahead and looked for the defcore meeting logs[0] (btw, seems like the
> bot
> died during the meeting) to get a better understanding of what Erno meant (I
> assumed the pings he mentioned came from the meeting and then confirmed it).
>
> From the small piece of conversation I could read, and based on the current
> status of development, priorities and support, I noticed a few "issues" that
> I
> believe are worth raising:
>
> 1. Glare's API is under discussion and it's a complementary service for
> Glance.
> [1] 2. Glare should not be a required API for every cloud, whereas Glance is
> and
> it should be kept that way for now. 3. Glare is not a drop-in replacement
> for
> Glance and it'll need way more discussions before that can happen.
>
> I do realize that I missed both meetings and that logs from one of them are
> not
> complete. I apologize if I've misinterpreted the intentions here. I do think
> engaiging with DefCore as early in the process as possible is good but I'd
> also
> like to clarify the intentions here before this escalates (again) into more
> confusion about what Glance's future looks like.
>
> So, to summarize, I don't think Glare should be added in DefCore in the near
> future. The Glance team should focus on fixing the current interoperability
> issues before we'll be able to actually try to build on top of the current
> API.

I was just about to type a response to this but saw Mikhail already
responded.  As he said the team was seeking guidance and wanted to be
sure they were proceeding in the right direction long term, not
pushing for an immediate inclusion.

I've shared my logs from the meeting here[1] which are complete, so
you can see the conversation in it's entirety.

[1]: http://paste.openstack.org/show/492753/

-Christopher


> Hope the above makes sense,
> Flavio
>
> [0]
> http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
> [1] https://review.openstack.org/#/c/283136
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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] [defcore][glance] Glare not defcore ready

[Mikhail Fedosin]

Hi Flavio! Thank you for the clarification.

I do realize that I missed both meetings and that logs from one of them are
> not
> complete. I apologize if I've misinterpreted the intentions here. I do
> think
> engaiging with DefCore as early in the process as possible is good but I'd
> also
> like to clarify the intentions here before this escalates (again) into more
> confusion about what Glance's future looks like.
>

I want to tell you that the intention of the DefCore meeting was not to
confuse more on the work, rather it was to get clarity on all the
constraints that we are stuck with. Currently we intend to keep our focus
on interoperability issues this cycle - API hardening being our first
priority, along with early adoption from Murano and Community App Catalog.

And also I want to assure the community that Glare is being developed
consistent with the API WG principles and in such a way that it could be
included in DefCore at the appropriate time.

Best regards,
Mikhail Fedosin

On Fri, Apr 1, 2016 at 6:02 PM, Flavio Percoco  wrote:

> Greetings,
>
> I missed yday's Glance meeting but I went ahead and read the logs. While I
> was
> at it, I read a sentence from Erno (under the Glare updates topic) that
> caught
> my eye:
>
> 14:06:27  About that. I got couple of pings last night
> asking wtf is
> going on. Could we please stop selling Glare as replacement for
> Glance at
> least until we have a) stable API and b) some level of track
> record/testing
> that it actually is successfully working
>
> I went ahead and looked for the defcore meeting logs[0] (btw, seems like
> the bot
> died during the meeting) to get a better understanding of what Erno meant
> (I
> assumed the pings he mentioned came from the meeting and then confirmed
> it).
>
> From the small piece of conversation I could read, and based on the current
> status of development, priorities and support, I noticed a few "issues"
> that I
> believe are worth raising:
>
> 1. Glare's API is under discussion and it's a complementary service for
> Glance.
> [1] 2. Glare should not be a required API for every cloud, whereas Glance
> is and
> it should be kept that way for now. 3. Glare is not a drop-in replacement
> for
> Glance and it'll need way more discussions before that can happen.
>
> I do realize that I missed both meetings and that logs from one of them
> are not
> complete. I apologize if I've misinterpreted the intentions here. I do
> think
> engaiging with DefCore as early in the process as possible is good but I'd
> also
> like to clarify the intentions here before this escalates (again) into more
> confusion about what Glance's future looks like.
>
> So, to summarize, I don't think Glare should be added in DefCore in the
> near
> future. The Glance team should focus on fixing the current interoperability
> issues before we'll be able to actually try to build on top of the current
> API.
>
> Hope the above makes sense,
> Flavio
>
> [0]
> http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
> [1] https://review.openstack.org/#/c/283136
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Monty Taylor]

On 04/01/2016 09:39 AM, Sean Dague wrote:

On 04/01/2016 10:35 AM, Monty Taylor wrote:

On 04/01/2016 09:16 AM, Sean Dague wrote:

On 04/01/2016 10:08 AM, Monty Taylor wrote:

On 04/01/2016 08:45 AM, Sean Dague wrote:

The glance v2 work is currently blocked as there is no active spec,
would be great if someone from the glance team could get that rolling
again.

I started digging back through the patches in detail to figure out if
there are some infrastructure bits we could get in early regardless.

#1 - new methods for glance xenserver plugin

Let's take a simplified approach on this patch -
https://review.openstack.org/#/c/266933 and only change the
xenapi/etc/xapi.d/plugins/ content in the following ways.

- add upload/download_vhd_glance2 methods. Don't add an api parameter.
Add these methods mostly via copy/paste as we're optimizing for
deleting
v1 not for fixing v1.

That will put some infrastructure in place so we can just call the v2
actions based on decision from higher up the stack.

#2 - move discover major version back to glanceclient -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108



I don't understand why this was ever in nova. This really should be

glanceclient.discover... something. It uses internal methods from
glanceclient and internal structures of the content returned.


FWIW, I use:

from glanceclient.common import utils as glance_utils
endpoint, detected_version = glance_utils.strip_version(endpoint)

To part of trying to figure this out as a consumer. Of course, that's
partially because like most of the openstack clients, there is no
exposed API for querying versions, since you have to tell the
constructor what major version you want to construct.


You can do that because you are using service catalogue entries for
glance. We're not there yet (and the path to get there is... odd for a
bunch of reasons).

The information that nova has is the config option api_servers -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25


Which are unversioned endpoints.


That just makes me want to cry.


Catching, if desired, should also be on the glanceclient side.
glanceclient.reset_version() could exist to clear any caching.

#3 - Ideally we'd also have a

client = glanceclient.AutoClient(endpoint, ... ) which basically does
glanceclient.discover and returns us the right client automatically.
client.version provides access to the version information if you
need to
figure out what version of a client you have.


You should just do:

import os_client_config

client = os_client_config.legacy_client('image') since all of that work
is pretty much already done.

If glanceclient grows the ability to be used without a priori knowledge
of the version, I'll certainly start to use it  there.


That assumes credentials locally, right? Nova is building glance clients
with the context it received the request in as -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85

- so this is happening as the same user as initiated the Nova API call.


Yah- that totally works - keystoneauth has a token plugin which takes
these parameters. Also, all of the constructors can take endpoint
overrides and doing so will skip the catalog.

So perhaps an initial step towards getting to be able to use the catalog
to find the endpoint would be to start using the API in such a way that
takes either an auth_url or an image_endpoint.


I guess I don't see how those would all connect together, as
os-client-config requires clouds.yaml which isn't a part of how we
deploy servers (unless I'm missing something). If you want to propose a
patch to Nova demonstrating how this would all work, that might make it
clearer.


AH. I understand the misunderstanding. occ doesn't require a clouds.yaml 
- that's just usually the most convenient way to express config in a 
context where you either have complex settings or multiple clouds.


All of the things you can do can also be done directly by parameters to 
the config constructor.


But I agree - the easiest way to take next step would be a patch - I'll 
cook one up and we can talk about it. It may be a terrible idea ... it 
just sounds so much like the problems overlap and solving them the first 
time really sucked, so I'd hate to watch someone else have to solve them 
again. I think I stabbed one of my eyes out the first time.


Monty


__
OpenStack Development Mailing 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] Floating IPs and Public IPs are not equivalent

[Fox, Kevin M]

And with external rbac in mitaka, you can finally have private floating ip's. :)

Thanks,
Kevin


From: Monty Taylor
Sent: Thursday, March 31, 2016 10:23:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Floating IPs and Public IPs are not equivalent

Just a friendly reminder to everyone - floating IPs are not synonymous
with Public IPs in OpenStack.

The most common (and growing, thank you to the beta of the new
Dreamcompute cloud) configuration for Public Clouds is directly assign
public IPs to VMs without requiring a user to create a floating IP.

I have heard that the require-floating-ip model is very common for
private clouds. While I find that even stranger, as the need to run NAT
inside of another NAT is bizarre, it is what it is.

Both models are common enough that pretty much anything that wants to
consume OpenStack VMs needs to account for both possibilities.

It would be really great if we could get the default config in devstack
to be to have a shared direct-attached network that can also have a
router attached to it and provider floating ips, since that scenario
actually allows interacting with both models (and is actually the most
common config across the OpenStack public clouds)

Monty

__
OpenStack Development Mailing 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] 答复: [Heat] Re-evaluate conditions specification

[Fox, Kevin M]

Why is imperative programming always brought up when discussing conditionals in 
the templates? We are not wanting anything imperative. The heat engine still 
picks the final ordering of things. We just want to give it all the valid 
options, and then enough knowledge to eliminate unacceptlable solutions. Maybe 
we are using the wrong term for them? Would 'constraint' suit the conversation 
better?

Thanks,
Kevin


From: Thomas Herve
Sent: Thursday, March 31, 2016 7:10:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On Thu, Mar 31, 2016 at 2:25 PM, Huangtianhua  wrote:
> The conditions function has been requested for a long time, and there have 
> been several previous discussions, which all ended up in debating the 
> implementation, and no result.
> https://review.openstack.org/#/c/84468/3/doc/source/template_guide/hot_spec.rst
> https://review.openstack.org/#/c/153771/1/specs/kilo/resource-enabled-meta-property.rst

And for a reason: this is a tricky issue, and introducing imperative
constructs in a template can lead to bad practices.

> I think we should focus on the simplest possible way(same as AWS) to meet the 
> user requirement, and follows the AWS, there is no doubt that we will get a 
> very good compatibility.
> And the patches are good in-progress. I don't want everything back to zero:)
> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/support-conditions-function

I don't say that you should scratch everything. I'm mostly OK with
what has been done, with the exception of the top-level conditions
section. Templates are our user interface, and we need to be very
careful when we introduce new things. 3 years ago following AWS was
the easy path because we didn't have much idea on what to do, but I
believe we now have enough background to be more innovative.

It's also slightly worrying that the spec "only" got 3 cores approving
it, especially on such a touchy subject. I'm guilty as others to not
have voiced my concerns then, though.

--
Thomas

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

[openstack-dev] OpenStack Developer Mailing List Digest March 26 – April 1

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/04/openstack-developer-mailing-list-digest-20160401/

SuccessBot Says
===
* Tonyb: Dims fixed the Routes 2.3 API break :) 
* pabelanger: migration from devstack-trusty to ubuntu-trusty complete! 
* Tell us yours via IRC with a message “#success [insert success]”.
* All: https://wiki.openstack.org/wiki/Successes


Voting for the Technical Committee Election Is Now Open
===
* We are selecting 7 TC members.
* Confirmed candidates [1]
* You are eligible to vote if you are a Foundation individual member [2] that
  also committed to one of the official projects [3] during the Liberty and
  Mitaka development.
* Important dates:
  - Election open: 2015-04-01 00:00 UTC
  - Election close: 2015-04-07 23:59 UTC
* More details on the election [4]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/091103.html


Release Process Changes For Official Projects
=
* The release team worked on automation for tagging and documenting [5]
  focusing on the projects with the release:managed tag.
* Second phase is to expand to all projects.
* The release team will be updating gerrit ACLs for projects to ensure they can
  handle releases and branching.
* Instead of tagging releases and then recording them in the release
  repository, all official teams can use the release repo to request new
  releases.
* If you're not familiar with the release process, review the README file in
  the openstack/releases repo [6].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html


Service Catalog TNG Work in Mitaka … Next Steps
===
* Mitaka included fact finding
* public / admin / internal url
  - Notion of an internal url is used in many deployments because there is
a belief it means there is no change for data transfer.
  - Some deployments make these all the same and use the network to ensure that
internal connections hit internal interfaces.
  - Next steps:
+ We need a set of user stories built from what we currently have.
* project_id optional in projects – good progress
  - project_id is hard coded into many urls for projects without any useful
reason.
  - Nova demonstrated removing this in micro version 2.18.
  - A patch  [7] is up for devstack to enable this.
  - Next steps:
+ Get other projects to remove project_id from their urls.
* Service types authority
  - We agreed we needed a place to recognize service types [8].
  - The assumption that there might be a single URL which describes an API for
a service is not an assumption we fulfill even for most services.
  - This bump led to [9] some shifted effort on API reference to RST work.
  - Next steps:
+ Finish API documentation conversion work.
+ Review patches for service type authority repo [10].
* Service catalog TNG Schema
  - We have some early work setting up a schema based on the known knowns, and
leaving some holes for the known unknowns until we get a few of these
locked down (types / allowed urls).
  - Next steps:
+ Review current schema.
* Weekly Meetings
  - The team has been meeting weekly in #openstack-meeting-cp until release
crunch and people got swamped.
  - The meeting will be on hiatus for now until after Austin summit, and then
start back up after the week of getting back.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090754.html


Oh Swagger, Where Art Thou?
===
* Previously it has been communicated of the move from WADL to Swagger for API
  reference information.
* It has been discovered that Swagger doesn't match all of our current API
  designs.
* There is a compute server reference documentation patch [11] using Sphinx,
  RST to do a near copy of the API reference page.
  - There is consensus with Nova-API team, API working group and others to go
forward with this.
* We can still find uses for Swagger for some projects that match the
  specification really well.
* Swagger for example doesn't support 
  - Showing the changes between micro versions.
  - Projects that have /actions resource allow multiple differing request
bodies.
* A new plan is coming, but for now the API reference and WADL files will
  remain in the api-site repository.
* There will be a specification and presentation in the upstream contributor's
  track about Swagger as a standard [12].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090659.html


Cross-Project Summit Session Proposals Due
==
* When: April 2nd
* Where: etherpad [13]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/091078.html


The Plan For the Final Week of the Mitaka Release
=
* We are approaching

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

[Steven Hardy]

On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote:
> On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter  wrote:
> > On 31/03/16 18:10, Zane Bitter wrote:
> >>
> >>
> >> I'm in favour of some sort of variable-based implementation for a few
> >> reasons. One is that (5) seems to come up fairly regularly in a complex
> >> deployment like TripleO. Another is that Fn::If feels awkward compared
> >> to get_variable.
> >
> >
> > I actually have to revise this last part after reviewing the patches.
> > get_variable can't replace Fn::If, because we'd still need to handle stuff
> > of the form:
> >
> > some_property: {if: [{get_variable: some_var},
> >  {get_resource: res1},
> >  {get_resource: res2}]
> >
> > where the alternatives can't come from a variable because they contain
> > resource references and we have said we'd constrain variables to be static.
> >
> > In fact the intrinsic functions that could be allowed in the first argument
> > to the {if: } function would have to constrained in the same way as the
> > constraint field in the resource, because we should only validate and obtain
> > dependencies from _one_ of the alternates, so we need to be able to
> > determine which one statically and not have to wait until the actual value
> > is resolved. This is possibly the strongest argument for keeping on the cfn
> > implementation course.
> 
> We talked about another possibilities on IRC: instead of having a new
> section, create a new resource OS::Heat::Value which can hold some
> data. It would look like that:
> 
> resources:
> is_prod:
> type: OS::Heat::Value
> properties:
> value: {equals: {get_param, env}, prod}}
> 
> my_resource:
> condition: {get_attr: [is_prod, value}}

Another alternative (which maybe you discussed, sorry I missed the IRC
chat) would be just to use parameters, as that's already conceptually where
we obtain values that are input to resources.

E.g:

parameters:
  env:
   type: string
   default: prod

  is_prod:
type: boolean
default: {equals: {get_param, env}}

>From an interface standpoint this seems much cleaner and more intuitive than
the other solutions discussed IMHO, but I suspect it's potentially harder to
implement.

Your original example gets much cleaner too if we allow all intrinsic function
(except get_attr) in the scope of parameters:

parameters:
  host:
type: string
  port:
type: string
  endpoint:
type: string
default:
  str_replace:
template:
   http://HOSTORT/
params:
   HOST: {get_param: host}
   PORT: {get_param: port}

Steve

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

Re: [openstack-dev] [nova] Which SSL ca_file does a person use, really?

[Matt Riedemann]

On 4/1/2016 11:07 AM, Matt Riedemann wrote:

We have a lot of CA file options in nova:

1. DEFAULT.ca_file - this is used in nova.crypto
2. ssl.ca_file - this is used when constructing glanceclient
3. DEFAULT.ssl_ca_file - this is used in nova.wsgi
4. vmware.ca_file - for connecting to vcenter
5. neutron.cafile - for constructing neutronclient
6. cinder.cafile - for constructing cinderclient
7. keystone_authtoken.cafile - for constructing keystoneauth
8. barbican.cafile - for constructing barbicanclient

As far as I can see none of these are deprecated. The keystone_auth one
is probably coming from one of the keystone library options, so we can't
do much about that.

But it seems like the first three, and then the other ones for
connecting to neutron/cinder/barbican clients could all be collapsed, or
is that not the intent?

I remember Matthew Gilliard working on something related to this at one
point where we were going to use a DictOpt where the default value comes
from ssl.ca_file (which is defined in oslo.service) but you could
override that for specific functions, like if you want different files
for connecting to the different clients.

Is anyone else working on something like this because it's super
confusing for deployers.



I found that old series if someone wants to work on this:

https://review.openstack.org/#/q/status:abandoned+project:openstack/nova+branch:master+topic:ssl-config-options

--

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] [nova] Which SSL ca_file does a person use, really?

[Matt Riedemann]

We have a lot of CA file options in nova:

1. DEFAULT.ca_file - this is used in nova.crypto
2. ssl.ca_file - this is used when constructing glanceclient
3. DEFAULT.ssl_ca_file - this is used in nova.wsgi
4. vmware.ca_file - for connecting to vcenter
5. neutron.cafile - for constructing neutronclient
6. cinder.cafile - for constructing cinderclient
7. keystone_authtoken.cafile - for constructing keystoneauth
8. barbican.cafile - for constructing barbicanclient

As far as I can see none of these are deprecated. The keystone_auth one 
is probably coming from one of the keystone library options, so we can't 
do much about that.


But it seems like the first three, and then the other ones for 
connecting to neutron/cinder/barbican clients could all be collapsed, or 
is that not the intent?


I remember Matthew Gilliard working on something related to this at one 
point where we were going to use a DictOpt where the default value comes 
from ssl.ca_file (which is defined in oslo.service) but you could 
override that for specific functions, like if you want different files 
for connecting to the different clients.


Is anyone else working on something like this because it's super 
confusing for deployers.


--

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] Announcement of new bandit-security-check gate

[Yegor Kotko]

Dear colleagues,

we want  to announce new gate bandit-security-check. The gate will be
applied to such projects:
openstack/fuel-web
openstack/fuel-agent
openstack/fuel-mirror
openstack/fuel-ostf
openstack/shotgun

It will work in non voting mode.
The bandit documentation can be found here
.
The job link .

Feel free to ask any questions and request any information
__
OpenStack Development Mailing 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] Newton virtual pre-summit sync

[Brian Rosmaita]

Tuesday, April 12 1400-1800 UTC works for me, I will attend.

On 3/31/16, 5:34 PM, "Nikhil Komawar"  wrote:

>Hi all,
>
>I'm excited to see you all Glancers at the Austin summit and discuss
>more on our project.
>
>Nevertheless, I feel that our summit conversations will have a lot more
>value if we establish some prior-context to the discussions and prepare
>ourselves for some of the sessions. Hence, I would like to call for a
>virtual sync meetup on the week of April 11th.
>
>My initial plan is to have a 4 hour sync on Tuesday April 12th, from
>1400-1800 UTC (we can decide on the length of the sessions and the
>required breaks later). But sending out this tentative plan to gauge the
>feasibility and interest.
>
>Please reply to this thread with your thoughts. If none, looking forward
>to seeing you at the event.
>
>P.S. based on the number of interested participants we can decide on the
>tool to be used.
>
>-- 
>
>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 Development Mailing 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]: Neutron naming legal issues

[Edgar Magana]

BTW. This is my proposal design for this summit t-shirts:

Yes, I run overcomplicated virtual networking in my Cloud

nova-network
quantum
neutron
nova-network ...
neutron
quantum

of course, after a few changes!

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, March 31, 2016 at 11:06 PM
To: Jimmy Akin >, "OpenStack 
Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [neutron]: Neutron naming legal issues



On 31 March 2016 at 22:46, Jimmy Akin 
> wrote:

Dear Neutrinos,

We've been following the project for quite some time.
To our satisfaction the project seems to have done well; the base line of
features that were available to the networking component of OpenStack
(then nova-network) has grown quite a bit and seem to have gained a
successful momentum with the communities, both development and
operators.

However, Neutron appears to be a trademarked name [1], and after thoroughly 
discussing the issue with our and Marvel' legal departments
both sides have reached the conclusion that a naming scheme is an obligatory 
amendment and unfortunately is the only viable option.

An obvious resolution to this issue is reverting the old "Quantum" name back.
However, this is subject to change and review from the PTL and as such, we'll 
shortly propose a relevant change to the review system.
We anticipate the review process to be be swift, to avoid further legal 
implications.

To be perfectly honest with you, I always liked the 'Quantum' name more.

With the ongoing release cycle called 'Newton', my hatred for the 'Neutron' 
name has increased, since I keep mispronouncing with 'Neutron' and vice versa.

Therefore I can't express my gratitude enough for this well timed proposal. You 
got my +2, though you got get behind governance change [1] first.

Happy hacking!
Armando,
Quantum (formerly known as Newton) PTL

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


Sincerely,
Jimmy J. Akin,
CIO,John F. Kennedy Space Center.

[1] https://en.wikipedia.org/wiki/Neutron_(Marvel_Comics)


__
OpenStack Development Mailing 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] [nova][neutron] What to do about booting into port_security_enabled=False networks?

[Matt Riedemann]

On 3/31/2016 8:42 AM, Sahid Orentino Ferdjaoui wrote:

On Wed, Mar 30, 2016 at 09:46:45PM -0500, Matt Riedemann wrote:



On 3/30/2016 5:55 PM, Armando M. wrote:



On 29 March 2016 at 18:55, Matt Riedemann > wrote:



On 3/29/2016 4:44 PM, Armando M. wrote:



On 29 March 2016 at 08:08, Matt Riedemann

>> wrote:

 Nova has had some long-standing bugs that Sahid is trying
to fix
 here [1].

 You can create a network in neutron with
 port_security_enabled=False. However, the bug is that since
Nova
 adds the 'default' security group to the request (if none are
 specified) when allocating networks, neutron raises an
error when
 you try to create a port on that network with a 'default'
security
 group.

 Sahid's patch simply checks if the network that we're going
to use
 has port_security_enabled and if it does not, no security
groups are
 applied when creating the port (regardless of what's
requested for
 security groups, which in nova is always at least 'default').

 There has been a similar attempt at fixing this [2]. That
change
 simply only added the 'default' security group when allocating
 networks with nova-network. It omitted the default security
group if
 using neutron since:

 a) If the network does not have port security enabled,
we'll blow up
 trying to add a port on it with the default security group.

 b) If the network does have port security enabled, neutron will
 automatically apply a 'default' security group to the port,
nova
 doesn't need to specify one.

 The problem both Feodor's and Sahid's patches ran into was
that the
 nova REST API adds a 'default' security group to the server
create
 response when using neutron if specific security groups
weren't on
 the server create request [3].

 This is clearly wrong in the case of
 network.port_security_enabled=False. When listing security
groups
 for an instance, they are correctly not listed, but the server
 create response is still wrong.

 So the question is, how to resolve this?  A few options
come to mind:

 a) Don't return any security groups in the server create
response
 when using neutron as the backend. Given by this point
we've cast
 off to the compute which actually does the work of network
 allocation, we can't call back into the network API to see what
 security groups are being used. Since we can't be sure, don't
 provide what could be false info.

 b) Add a new method to the network API which takes the
requested
 networks from the server create request and returns a best
guess if
 security groups are going to be applied or not. In the case of
 network.port_security_enabled=False, we know a security
group won't
 be applied so the method returns False. If there is
 port_security_enabled, we return whatever security group was
 requested (or 'default'). If there are multiple networks on the
 request, we return the security groups that will be applied
to any
 networks that have port security enabled.

 Option (b) is obviously more intensive and requires hitting the
 neutron API from nova API before we respond, which we'd like to
 avoid if possible. I'm also not sure what it means for the
 auto-allocated-topology (get-me-a-network) case. With a
standard
 devstack setup, a network created via the
auto-allocated-topology
 API has port_security_enabled=True, but I also have the 'Port
 Security' extension enabled and the default public external
network
 has port_security_enabled=True. What if either of those are
False
 (or the port security extension is disabled)? Does the
 auto-allocated network inherit port_security_enabled=False?
We could
 duplicate that logic in Nova, but it's more proxy work that
we would
 like to avoid.


Port security on the external network has no role in this
because this
is not the network you'd be creating ports on. Even if it had
port-security=False, an 

Re: [openstack-dev] [neutron]: Neutron naming legal issues

[Edgar Magana]

Let’s keep the name and wait for the movie where we all become the bad guys! 

Edgar




On 3/31/16, 10:46 PM, "Jimmy Akin"  wrote:

>
>Dear Neutrinos,
>
>We've been following the project for quite some time.
>To our satisfaction the project seems to have done well; the base line of
>features that were available to the networking component of OpenStack
>(then nova-network) has grown quite a bit and seem to have gained a
>successful momentum with the communities, both development and
>operators.
>
>However, Neutron appears to be a trademarked name [1], and 
>after thoroughly discussing the issue with our and Marvel' legal departments
>both sides have reached the conclusion that a naming scheme is an obligatory 
>amendment and unfortunately is the only viable option.
>
>An obvious resolution to this issue is reverting the old "Quantum" name back.
>However, this is subject to change and review from the PTL and as such, we'll 
>shortly propose a relevant change to the review system.
>We anticipate the review process to be be swift, to avoid further legal 
>implications.
>
>Sincerely,
>Jimmy J. Akin,
>CIO,John F. Kennedy Space Center.
>
>[1] https://en.wikipedia.org/wiki/Neutron_(Marvel_Comics)
>
>
>__
>OpenStack Development Mailing 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] [kolla][tc] [security] threat analysis, tags, and the road ahead

[Hayes, Graham]

>> On 3/31/16, 12:15 PM, "michael mccune"  wrote:
>>
>>> 
 >>>
>>> one of the big questions seems to be who should be doing these analysis,
>>> especially given that the ossp has not formally codified the practice
>>> yet, and the complexity involved. although currently the
>>> vulnerability:managed tag suggests that a third party review should be
>>> done, this may prove difficult to scale in practice. i feel that it
>>> would be in the best interests of the wider openstack community if the
>>> ossp works towards creating instructional material that can empower the
>>> project teams to start their own analyses.
>>>
>>> ultimately, having a third-party review of a project is worthy goal, but
>>> this has to be tempered with the reality that a single team will not be
>>> able to scale out and provide thorough analyses for all projects. to
>>> that extent, the ossp should work, initially, to help a few teams get
>>> these analyses completed and in the process create a set of useful tools
>>> (docs, guides, diagrams, foil-hat wearing pamphlets) to help further the
>>> effort.
>>>
>>> i would like to propose that the threat analysis portion of the
>>> vulnerability:managed tag be modified with the goal of having the
>>> project teams create their own analyses, with an extended third-party
>>> review to be performed afterwards. in this respect, the scale issue can
>>> be addressed, as well as the issue of project domain knowledge. it makes
>>> much more sense to me to have the project team creating the initial work
>>> here as they will know the areas, and architectures, that will need the
>>> most attention.
>>>
>>> 
>>>

If a team has already done a TA (e.g. as part of an internal product
TA) (and produced all the documentation) would this meet the
requirements?

I ask, as Designate looks like it meets nearly  all the current 
requirements - the only outstanding question in my mind was the
Threat Analysis

>>> [1]:
>>> http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31-
>>> 17.00.log.txt
>>>
>>> [2]:
>>> http://governance.openstack.org/reference/tags/vulnerability_managed.html
>>>
>>> [3]: https://review.openstack.org/#/c/220712/
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [neutron]: Neutron naming legal issues

[Morales, Victor]

Jim, 

Did you verify with Marvel if it's possible to keep the name and use
his hero. In that way we could be the first OpenStack project to have
one.

Victor Morales

On Fri, 2016-04-01 at 08:46 +0300, Jimmy Akin wrote:
> Dear Neutrinos,
> 
> We've been following the project for quite some time.
> To our satisfaction the project seems to have done well; the base
> line of
> features that were available to the networking component of OpenStack
> (then nova-network) has grown quite a bit and seem to have gained a
> successful momentum with the communities, both development and
> operators.
> 
> However, Neutron appears to be a trademarked name [1], and 
> after thoroughly discussing the issue with our and Marvel' legal
> departments
> both sides have reached the conclusion that a naming scheme is an
> obligatory amendment and unfortunately is the only viable option.
> 
> An obvious resolution to this issue is reverting the old "Quantum"
> name back.
> However, this is subject to change and review from the PTL and as
> such, we'll shortly propose a relevant change to the review system.
> We anticipate the review process to be be swift, to avoid further
> legal implications.
> 
> Sincerely,
> Jimmy J. Akin,
> CIO,John F. Kennedy Space Center.
> 
> [1] https://en.wikipedia.org/wiki/Neutron_(Marvel_Comics)
> 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

[Victor Stinner]

Le 01/04/2016 03:12, Assaf Muller a écrit :

2) Now, transform yourself six to twelve months in the future. We now
face a new problem. (...) I hereby propose that we remove the
tests. (...) Needless to say, my
proposal keeps pep8 in place. We all know how important a consistent
style is.


The good news is that it fits well with the next Python version, Python 
8, which will run pep8 checks for you when you import a module!

https://mail.python.org/pipermail/python-dev/2016-March/143603.html

It makes pep8 jobs useless.

Victor

__
OpenStack Development Mailing 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] Re-evaluate conditions specification

[Zane Bitter]

On 01/04/16 10:15, Thomas Herve wrote:

On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter  wrote:

On 31/03/16 18:10, Zane Bitter wrote:



I'm in favour of some sort of variable-based implementation for a few
reasons. One is that (5) seems to come up fairly regularly in a complex
deployment like TripleO. Another is that Fn::If feels awkward compared
to get_variable.



I actually have to revise this last part after reviewing the patches.
get_variable can't replace Fn::If, because we'd still need to handle stuff
of the form:

 some_property: {if: [{get_variable: some_var},
  {get_resource: res1},
  {get_resource: res2}]

where the alternatives can't come from a variable because they contain
resource references and we have said we'd constrain variables to be static.

In fact the intrinsic functions that could be allowed in the first argument
to the {if: } function would have to constrained in the same way as the
constraint field in the resource, because we should only validate and obtain
dependencies from _one_ of the alternates, so we need to be able to
determine which one statically and not have to wait until the actual value
is resolved. This is possibly the strongest argument for keeping on the cfn
implementation course.


We talked about another possibilities on IRC: instead of having a new
section, create a new resource OS::Heat::Value which can hold some
data. It would look like that:

resources:
 is_prod:
 type: OS::Heat::Value
 properties:
 value: {equals: {get_param, env}, prod}}


We could even get fancy and have an optional 'type' property for type 
checking.



 my_resource:
 condition: {get_attr: [is_prod, value}}


Ah, I think I misunderstood the conversation on IRC.

Using a value from get_attr for a condition like this doesn't work, at 
least with something similar to the current implementation, because the 
result would only be known once the is_prod resource is created, but 
currently at least we exclude my_resource from the list of resource 
definitions that we return when we ask the template what it contains, 
long before we create any resources. It's possible to imagine a world in 
which all of the resource definitions are returned and we decide at the 
point of creating/updating what to do with them (create/not 
create/delete), but it would require extensive changes throughout Heat. 
The current proposed implementation is much, much safer.


What this would be *great* for is to provide the variable functionality 
that things like TripleO could really use, without needing to affect the 
implementation of conditionals at all.



Sounds like it would be fairly flexible, really easy to implement, and
solve most of the issues I can think of (including being included in
the dependency resolution mechanism for free).


Adding OS::Heat::Value for variables & sticking with the existing spec 
for the conditional resources gets my +1. Seems less complicated all round.


cheers,
Zane.


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

Re: [openstack-dev] [Glance] Newton virtual pre-summit sync

[Nikhil Komawar]

Matt, thanks for sending the update!

My comments inline.

On 4/1/16 10:54 AM, Matt Riedemann wrote:
>
>
> On 4/1/2016 7:56 AM, Flavio Percoco wrote:
>> On 31/03/16 17:34 -0400, Nikhil Komawar wrote:
>>> Hi all,
>>>
>>> I'm excited to see you all Glancers at the Austin summit and discuss
>>> more on our project.
>>>
>>> Nevertheless, I feel that our summit conversations will have a lot more
>>> value if we establish some prior-context to the discussions and prepare
>>> ourselves for some of the sessions. Hence, I would like to call for a
>>> virtual sync meetup on the week of April 11th.
>>>
>>> My initial plan is to have a 4 hour sync on Tuesday April 12th, from
>>> 1400-1800 UTC (we can decide on the length of the sessions and the
>>> required breaks later). But sending out this tentative plan to gauge
>>> the
>>> feasibility and interest.
>>
>> Happy to join!
>>
>>> Please reply to this thread with your thoughts. If none, looking
>>> forward
>>> to seeing you at the event.
>>>
>>> P.S. based on the number of interested participants we can decide on
>>> the
>>> tool to be used.
>>
>>
>> We can use my bluejeans bridge. It work fairly well for the virtual
>> mid-cycle we
>> did a couple of months ago.
>>
>> Flavio
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> To update the rest of the glance team, we're planning on a nova/glance
> session during the design summit, right now that's looking like
> Thursday afternoon in one of nova's fishbowl sessions.
>

+1

> We really need to make progress before the summit on getting a clear
> picture of the steps to get glance v2 supported in nova. Some details
> are in an etherpad here [1].

Definitely and thank you.

>
> Sean Dague sent an email this morning on some basic baby steps there.
>

#action: nikhil to research on the intricate details of the proposal

> I've asked Nikhil that the glance v2 spec for nova be cleaned up and
> re-proposed for newton by Wednesday of next week. Nikhil and Mike
> might need some help from others on the glance team there.
>

Mike and I are working on this. I had a sync with Mike, this morning and
the spec should be up Mon/Tues.

> There are other things in that etherpad that I think glance wants to
> talk about with nova at the summit, but I really think those are just
> distractions right now. The top priority is glance v2 support in nova,
> let's just focus on that.
>

Makes sense.

> We might need a couple of meetings before the summit to make sure
> we're on a good footing with the plan when we get in person so we can
> iron out any hairy details during the design summit.
>
> [1] https://etherpad.openstack.org/p/nova-glance-newton
>

I agree, would love to have a structured conversation at the summit
rather than free form.

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [docs] [api] Oh Swagger, where art thou?

[Anne Gentle]

On Thu, Mar 31, 2016 at 11:22 AM, Jim Rollenhagen 
wrote:

> On Thu, Mar 31, 2016 at 09:50:48AM -0400, Sean Dague wrote:
> > On 03/31/2016 09:43 AM, Jim Rollenhagen wrote:
> > > On Thu, Mar 31, 2016 at 08:43:29AM -0400, Sean Dague wrote:
> > >> Some more details on progress, because this is getting closer every
> day.
> > >>
> > >> There is now an api-ref target on the Nova project. The entire work in
> > >> progress stream has been rebased into 2 patches to a top level
> api-ref/
> > >> directory structure in the Nova tree -
> > >>
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:wip_api_docs2
> > >>
> > >> That is a 2 patch series. The first is the infrastructure, the second
> is
> > >> the content for 2 resources (versions and servers). The rendered
> output
> > >> for this is at -
> > >>
> http://docs-draft.openstack.org/63/298763/4/check/gate-nova-api-ref/6983838//api-ref/build/html/
> > >> (you can also pull and build locally with tox -e api-ref)
> > >>
> > >> Karen, Auggy, and Anne continue to work on the wadl data translator
> > >> using the wadl2rst project and fairy-slipper to get various pieces of
> > >> the structured data over. Hopefully we'll see some of those translated
> > >> stacks rendering soon in patch sets.
> > >
> > > I assume at some point we'll be pulling the sphinx extension out to a
> > > separate project so that other projects can use this too? :)
> > >
> > > // jim
> >
> > Yes. I feel like it's probably a milestone 2 activity. Fixing styling
> > and error handling is a lot faster in tree while we sort out all the
> > issues. Once it's good we can move things into something that's pip
> > installable.
>
> Sounds good, thanks for pushing on this. Looking forward to using it in
> ironic. :)


Hi Jim,
A tidbit just for ironic, please review
https://review.openstack.org/#/c/245459 and then we can use that content to
migrate over with the tooling we're creating now. With a good technical
review now your content will be in good shape.
Thanks,
Anne


>
> // jim
>
> >
> >   -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
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [defcore][glance] Glare not defcore ready

[Flavio Percoco]

Greetings,

I missed yday's Glance meeting but I went ahead and read the logs. While I was
at it, I read a sentence from Erno (under the Glare updates topic) that caught
my eye:

14:06:27  About that. I got couple of pings last night asking 
wtf is
going on. Could we please stop selling Glare as replacement for Glance 
at
least until we have a) stable API and b) some level of track 
record/testing
that it actually is successfully working

I went ahead and looked for the defcore meeting logs[0] (btw, seems like the bot
died during the meeting) to get a better understanding of what Erno meant (I
assumed the pings he mentioned came from the meeting and then confirmed it).

From the small piece of conversation I could read, and based on the current
status of development, priorities and support, I noticed a few "issues" that I
believe are worth raising:

1. Glare's API is under discussion and it's a complementary service for Glance.
[1] 2. Glare should not be a required API for every cloud, whereas Glance is and
it should be kept that way for now. 3. Glare is not a drop-in replacement for
Glance and it'll need way more discussions before that can happen.

I do realize that I missed both meetings and that logs from one of them are not
complete. I apologize if I've misinterpreted the intentions here. I do think
engaiging with DefCore as early in the process as possible is good but I'd also
like to clarify the intentions here before this escalates (again) into more
confusion about what Glance's future looks like.

So, to summarize, I don't think Glare should be added in DefCore in the near
future. The Glance team should focus on fixing the current interoperability
issues before we'll be able to actually try to build on top of the current API.

Hope the above makes sense,
Flavio

[0] 
http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
[1] https://review.openstack.org/#/c/283136

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

[Aleksandr Didenko]

One more thing about spec to fixture mapping [0]. What if instead of:

# RUN: (hiera1) (facts1)

we'll use

# RUN: (roles_array1) (facts1)

?

We don't need to duplicate complicated task graph calculations to
understand which task to execute, because we don't care about tasks
ordering and dependencies in noop tests. All we need is to map rspec task
tests to astute.yaml fixtures. And it could be done via roles.

Regards,
Alex

[0]
https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations


On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko 
wrote:

> Hi.
>
>   As you may know, we're still using some very old astute.yaml fixtures
> (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have
> problems with fixture-to-rspec mapping [1]. So we've started to work on
> those problems [2].
>
>   So please be aware of upcoming changes in noop rspec fixtures and tests.
> If you see, that some important fixtures are missing (thus not covered by
> tests) please let me know in this email thread or via IRC/email/slack.
>
>   Also, we should stop updating astute.yaml fixtures manually and start
> using some kind of automation approach instead [3][4]. I propose to use [5]
> script until we find a better solution. So if you want to add some new
> astute.yaml fixture for noop tests, please propose a patch to this script
> instead of uploading yaml file.
>
> Currently the following is missing in the new set of fixtures for fuel-9.0:
> - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
> properly enable it via nailgun, any help is much appreciated)
> - selective ssl fixtures - since configuration data is not serialized from
> nailgun, I think that we should move this into 'hiera/override' along with
> implementation of new hiera overrides tests workflow [6]
> - vmware related fixtures
>
> Please feel free to share your ideas/comments on this topic.
>
> Thanks,
> Alex
>
> [0] https://bugs.launchpad.net/fuel/+bug/1535339
> [1]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
> [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
> [3]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
> [4]
> https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
> [5]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
> [6] https://bugs.launchpad.net/fuel/+bug/1564919
>
__
OpenStack Development Mailing 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] Newton virtual pre-summit sync

[Matt Riedemann]

On 4/1/2016 7:56 AM, Flavio Percoco wrote:

On 31/03/16 17:34 -0400, Nikhil Komawar wrote:

Hi all,

I'm excited to see you all Glancers at the Austin summit and discuss
more on our project.

Nevertheless, I feel that our summit conversations will have a lot more
value if we establish some prior-context to the discussions and prepare
ourselves for some of the sessions. Hence, I would like to call for a
virtual sync meetup on the week of April 11th.

My initial plan is to have a 4 hour sync on Tuesday April 12th, from
1400-1800 UTC (we can decide on the length of the sessions and the
required breaks later). But sending out this tentative plan to gauge the
feasibility and interest.


Happy to join!


Please reply to this thread with your thoughts. If none, looking forward
to seeing you at the event.

P.S. based on the number of interested participants we can decide on the
tool to be used.



We can use my bluejeans bridge. It work fairly well for the virtual
mid-cycle we
did a couple of months ago.

Flavio



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



To update the rest of the glance team, we're planning on a nova/glance 
session during the design summit, right now that's looking like Thursday 
afternoon in one of nova's fishbowl sessions.


We really need to make progress before the summit on getting a clear 
picture of the steps to get glance v2 supported in nova. Some details 
are in an etherpad here [1].


Sean Dague sent an email this morning on some basic baby steps there.

I've asked Nikhil that the glance v2 spec for nova be cleaned up and 
re-proposed for newton by Wednesday of next week. Nikhil and Mike might 
need some help from others on the glance team there.


There are other things in that etherpad that I think glance wants to 
talk about with nova at the summit, but I really think those are just 
distractions right now. The top priority is glance v2 support in nova, 
let's just focus on that.


We might need a couple of meetings before the summit to make sure we're 
on a good footing with the plan when we get in person so we can iron out 
any hairy details during the design summit.


[1] https://etherpad.openstack.org/p/nova-glance-newton

--

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

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Sean Dague]

On 04/01/2016 10:35 AM, Monty Taylor wrote:
> On 04/01/2016 09:16 AM, Sean Dague wrote:
>> On 04/01/2016 10:08 AM, Monty Taylor wrote:
>>> On 04/01/2016 08:45 AM, Sean Dague wrote:
 The glance v2 work is currently blocked as there is no active spec,
 would be great if someone from the glance team could get that rolling
 again.

 I started digging back through the patches in detail to figure out if
 there are some infrastructure bits we could get in early regardless.

 #1 - new methods for glance xenserver plugin

 Let's take a simplified approach on this patch -
 https://review.openstack.org/#/c/266933 and only change the
 xenapi/etc/xapi.d/plugins/ content in the following ways.

 - add upload/download_vhd_glance2 methods. Don't add an api parameter.
 Add these methods mostly via copy/paste as we're optimizing for
 deleting
 v1 not for fixing v1.

 That will put some infrastructure in place so we can just call the v2
 actions based on decision from higher up the stack.

 #2 - move discover major version back to glanceclient -
 https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108



 I don't understand why this was ever in nova. This really should be

 glanceclient.discover... something. It uses internal methods from
 glanceclient and internal structures of the content returned.
>>>
>>> FWIW, I use:
>>>
>>> from glanceclient.common import utils as glance_utils
>>> endpoint, detected_version = glance_utils.strip_version(endpoint)
>>>
>>> To part of trying to figure this out as a consumer. Of course, that's
>>> partially because like most of the openstack clients, there is no
>>> exposed API for querying versions, since you have to tell the
>>> constructor what major version you want to construct.
>>
>> You can do that because you are using service catalogue entries for
>> glance. We're not there yet (and the path to get there is... odd for a
>> bunch of reasons).
>>
>> The information that nova has is the config option api_servers -
>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25
>>
>>
>> Which are unversioned endpoints.
> 
> That just makes me want to cry.
> 
 Catching, if desired, should also be on the glanceclient side.
 glanceclient.reset_version() could exist to clear any caching.

 #3 - Ideally we'd also have a

 client = glanceclient.AutoClient(endpoint, ... ) which basically does
 glanceclient.discover and returns us the right client automatically.
 client.version provides access to the version information if you
 need to
 figure out what version of a client you have.
>>>
>>> You should just do:
>>>
>>> import os_client_config
>>>
>>> client = os_client_config.legacy_client('image') since all of that work
>>> is pretty much already done.
>>>
>>> If glanceclient grows the ability to be used without a priori knowledge
>>> of the version, I'll certainly start to use it  there.
>>
>> That assumes credentials locally, right? Nova is building glance clients
>> with the context it received the request in as -
>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85
>>
>> - so this is happening as the same user as initiated the Nova API call.
> 
> Yah- that totally works - keystoneauth has a token plugin which takes
> these parameters. Also, all of the constructors can take endpoint
> overrides and doing so will skip the catalog.
> 
> So perhaps an initial step towards getting to be able to use the catalog
> to find the endpoint would be to start using the API in such a way that
> takes either an auth_url or an image_endpoint.

I guess I don't see how those would all connect together, as
os-client-config requires clouds.yaml which isn't a part of how we
deploy servers (unless I'm missing something). If you want to propose a
patch to Nova demonstrating how this would all work, that might make it
clearer.

-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] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Monty Taylor]

On 04/01/2016 09:16 AM, Sean Dague wrote:

On 04/01/2016 10:08 AM, Monty Taylor wrote:

On 04/01/2016 08:45 AM, Sean Dague wrote:

The glance v2 work is currently blocked as there is no active spec,
would be great if someone from the glance team could get that rolling
again.

I started digging back through the patches in detail to figure out if
there are some infrastructure bits we could get in early regardless.

#1 - new methods for glance xenserver plugin

Let's take a simplified approach on this patch -
https://review.openstack.org/#/c/266933 and only change the
xenapi/etc/xapi.d/plugins/ content in the following ways.

- add upload/download_vhd_glance2 methods. Don't add an api parameter.
Add these methods mostly via copy/paste as we're optimizing for deleting
v1 not for fixing v1.

That will put some infrastructure in place so we can just call the v2
actions based on decision from higher up the stack.

#2 - move discover major version back to glanceclient -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108


I don't understand why this was ever in nova. This really should be

glanceclient.discover... something. It uses internal methods from
glanceclient and internal structures of the content returned.


FWIW, I use:

from glanceclient.common import utils as glance_utils
endpoint, detected_version = glance_utils.strip_version(endpoint)

To part of trying to figure this out as a consumer. Of course, that's
partially because like most of the openstack clients, there is no
exposed API for querying versions, since you have to tell the
constructor what major version you want to construct.


You can do that because you are using service catalogue entries for
glance. We're not there yet (and the path to get there is... odd for a
bunch of reasons).

The information that nova has is the config option api_servers -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25

Which are unversioned endpoints.


That just makes me want to cry.


Catching, if desired, should also be on the glanceclient side.
glanceclient.reset_version() could exist to clear any caching.

#3 - Ideally we'd also have a

client = glanceclient.AutoClient(endpoint, ... ) which basically does
glanceclient.discover and returns us the right client automatically.
client.version provides access to the version information if you need to
figure out what version of a client you have.


You should just do:

import os_client_config

client = os_client_config.legacy_client('image') since all of that work
is pretty much already done.

If glanceclient grows the ability to be used without a priori knowledge
of the version, I'll certainly start to use it  there.


That assumes credentials locally, right? Nova is building glance clients
with the context it received the request in as -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85
- so this is happening as the same user as initiated the Nova API call.


Yah- that totally works - keystoneauth has a token plugin which takes 
these parameters. Also, all of the constructors can take endpoint 
overrides and doing so will skip the catalog.


So perhaps an initial step towards getting to be able to use the catalog 
to find the endpoint would be to start using the API in such a way that 
takes either an auth_url or an image_endpoint.



The on-behalf-of needs here make this a bit more complicated.




__
OpenStack Development Mailing 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][stable] RDO needs stable/mitaka branches for subprojects WAS: Re: [Rdo-list] RDO Mitaka RC1 current status - testers requested

[Ihar Hrachyshka]

Haïkel  wrote:


2016-04-01 16:17 GMT+02:00 Ihar Hrachyshka :

Haïkel  wrote:



Do we want to raise those issues to networking vendors? Do we have a  
list of

what’s required from them for RDO?

Ihar


Yes, we need to raise their attention about this issue.

As a distribution, it would help if they do proper releases (from
higher to lesser priority)
* tagged releases
* stable branches
* tarballs uploaded

Bare minimum is tagging releases and documented compatibility against
neutron releases, as our CI can't test these backends features.

Regards,
H.


Hi all,

it seems that RDO project needs networking-* subprojects to create  
stable/mitaka branches, tag releases from there, and upload tarballs to  
pypi, to be able to consume the code for those projects.


I presume it’s not just RDO, but other distributions that are interested in  
it.


With that in mind, I wonder what’s the strategy for subprojects for Mitaka?  
Do we set any guidelines for them to spin off stable/mitaka branches or  
trigger releases in due time? How are distributions supposed to know which  
tags for those subprojects to use for Mitaka?


The original thread is:  
https://www.redhat.com/archives/rdo-list/2016-April/msg2.html


Ihar

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

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

[Clark, Robert Graham]

Thanks Steve, Mike,

We’ve had a lot more traction with this latest incarnation of TA. I’m 
very much looking forward to working through the process with the
wider community.

-Rob



On 31/03/2016 20:44, "Steven Dake (stdake)"  wrote:

>Including tc and kolla
>
>Michael,
>
>Sounds good.  I'll get the governance changes rolling for debate at the
>next TC meeting.
>
>Note I added this cross project topic for discussion Tuesday at summit
>(last item in the list)
>https://etherpad.openstack.org/p/newton-cross-project-sessions
>
>Regards,
>-steve
>
>On 3/31/16, 12:15 PM, "michael mccune"  wrote:
>
>>hey all,
>>
>>at the most recent ossp meeting[1], there was some extended discussion
>>about threat analysis and the work that is being done to push this
>>forward.
>>
>>in this discussion, there were several topics brought up around the
>>process for doing these analyses on current projects and how the ossp
>>should proceed especially with respect to the "vulnerability:managed"
>>tag[2].
>>
>>as for the threat analysis process, there are still several questions
>>which need to be answered:
>>
>>* what is the process for performing an analysis
>>
>>* how will an analysis be formally recognized and approved
>>
>>* who will be doing these analyses
>>
>>* does it make sense to keep the analysis process strictly limited to
>>the vmt
>>
>>* how to address commonalities and differences between a developer
>>oriented analysis and a deployer oriented analysis
>>
>>these questions all feed into another related topic, which is the
>>proposed initial threat analysis for kolla which has been suggested to
>>start at the upcoming austin summit.
>>
>>i wanted to capture some of the discussion happening around this topic,
>>and continue the ball rolling as to how we will solve these questions as
>>we head to summit.
>>
>>one of the big questions seems to be who should be doing these analysis,
>>especially given that the ossp has not formally codified the practice
>>yet, and the complexity involved. although currently the
>>vulnerability:managed tag suggests that a third party review should be
>>done, this may prove difficult to scale in practice. i feel that it
>>would be in the best interests of the wider openstack community if the
>>ossp works towards creating instructional material that can empower the
>>project teams to start their own analyses.
>>
>>ultimately, having a third-party review of a project is worthy goal, but
>>this has to be tempered with the reality that a single team will not be
>>able to scale out and provide thorough analyses for all projects. to
>>that extent, the ossp should work, initially, to help a few teams get
>>these analyses completed and in the process create a set of useful tools
>>(docs, guides, diagrams, foil-hat wearing pamphlets) to help further the
>>effort.
>>
>>i would like to propose that the threat analysis portion of the
>>vulnerability:managed tag be modified with the goal of having the
>>project teams create their own analyses, with an extended third-party
>>review to be performed afterwards. in this respect, the scale issue can
>>be addressed, as well as the issue of project domain knowledge. it makes
>>much more sense to me to have the project team creating the initial work
>>here as they will know the areas, and architectures, that will need the
>>most attention.
>>
>>as the ossp build better tools for generating these analyses they will
>>be in a much better position to guide project teams in their initial
>>analyses, with the ultimate goal of having the ossp, and/or vmt, perform
>>the third-party audit for application of the tag. i have a feeling we
>>will also discover much overlap between the developer and deployer
>>oriented analyses, and these overlaps will help to strengthen the
>>process for all involved.
>>
>>finally, the austin summit, and proposed kolla review, provide a great
>>opportunity for the ossp to put "rubber on the road" with respect to
>>this process. although a full analysis may not be accomplished during
>>the summit, we can definitely achieve the goal of defining this process
>>much better and creating more guidance for all projects that wish to
>>follow this path, as well as having kolla solidly on the way to having a
>>full threat analysis ready for third-party review.
>>
>>thoughts?
>>
>>
>>regards,
>>mike
>>
>>
>>[1]: 
>>http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31-
>>17.00.log.txt
>>
>>[2]: 
>>http://governance.openstack.org/reference/tags/vulnerability_managed.html
>>
>>[3]: https://review.openstack.org/#/c/220712/
>>
>>__
>>OpenStack Development Mailing 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 

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Sean Dague]

On 04/01/2016 10:08 AM, Monty Taylor wrote:
> On 04/01/2016 08:45 AM, Sean Dague wrote:
>> The glance v2 work is currently blocked as there is no active spec,
>> would be great if someone from the glance team could get that rolling
>> again.
>>
>> I started digging back through the patches in detail to figure out if
>> there are some infrastructure bits we could get in early regardless.
>>
>> #1 - new methods for glance xenserver plugin
>>
>> Let's take a simplified approach on this patch -
>> https://review.openstack.org/#/c/266933 and only change the
>> xenapi/etc/xapi.d/plugins/ content in the following ways.
>>
>> - add upload/download_vhd_glance2 methods. Don't add an api parameter.
>> Add these methods mostly via copy/paste as we're optimizing for deleting
>> v1 not for fixing v1.
>>
>> That will put some infrastructure in place so we can just call the v2
>> actions based on decision from higher up the stack.
>>
>> #2 - move discover major version back to glanceclient -
>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108
>>
>>
>> I don't understand why this was ever in nova. This really should be
>>
>> glanceclient.discover... something. It uses internal methods from
>> glanceclient and internal structures of the content returned.
> 
> FWIW, I use:
> 
> from glanceclient.common import utils as glance_utils
> endpoint, detected_version = glance_utils.strip_version(endpoint)
> 
> To part of trying to figure this out as a consumer. Of course, that's
> partially because like most of the openstack clients, there is no
> exposed API for querying versions, since you have to tell the
> constructor what major version you want to construct.

You can do that because you are using service catalogue entries for
glance. We're not there yet (and the path to get there is... odd for a
bunch of reasons).

The information that nova has is the config option api_servers -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25

Which are unversioned endpoints.

>> Catching, if desired, should also be on the glanceclient side.
>> glanceclient.reset_version() could exist to clear any caching.
>>
>> #3 - Ideally we'd also have a
>>
>> client = glanceclient.AutoClient(endpoint, ... ) which basically does
>> glanceclient.discover and returns us the right client automatically.
>> client.version provides access to the version information if you need to
>> figure out what version of a client you have.
> 
> You should just do:
> 
> import os_client_config
> 
> client = os_client_config.legacy_client('image') since all of that work
> is pretty much already done.
> 
> If glanceclient grows the ability to be used without a priori knowledge
> of the version, I'll certainly start to use it  there.

That assumes credentials locally, right? Nova is building glance clients
with the context it received the request in as -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85
- so this is happening as the same user as initiated the Nova API call.

The on-behalf-of needs here make this a bit more complicated.

-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] 答复: [Heat] Re-evaluate conditions specification

[Thomas Herve]

On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter  wrote:
> On 31/03/16 18:10, Zane Bitter wrote:
>>
>>
>> I'm in favour of some sort of variable-based implementation for a few
>> reasons. One is that (5) seems to come up fairly regularly in a complex
>> deployment like TripleO. Another is that Fn::If feels awkward compared
>> to get_variable.
>
>
> I actually have to revise this last part after reviewing the patches.
> get_variable can't replace Fn::If, because we'd still need to handle stuff
> of the form:
>
> some_property: {if: [{get_variable: some_var},
>  {get_resource: res1},
>  {get_resource: res2}]
>
> where the alternatives can't come from a variable because they contain
> resource references and we have said we'd constrain variables to be static.
>
> In fact the intrinsic functions that could be allowed in the first argument
> to the {if: } function would have to constrained in the same way as the
> constraint field in the resource, because we should only validate and obtain
> dependencies from _one_ of the alternates, so we need to be able to
> determine which one statically and not have to wait until the actual value
> is resolved. This is possibly the strongest argument for keeping on the cfn
> implementation course.

We talked about another possibilities on IRC: instead of having a new
section, create a new resource OS::Heat::Value which can hold some
data. It would look like that:

resources:
is_prod:
type: OS::Heat::Value
properties:
value: {equals: {get_param, env}, prod}}

my_resource:
condition: {get_attr: [is_prod, value}}


Sounds like it would be fairly flexible, really easy to implement, and
solve most of the issues I can think of (including being included in
the dependency resolution mechanism for free).

-- 
Thomas

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

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Monty Taylor]

On 04/01/2016 08:45 AM, Sean Dague wrote:

The glance v2 work is currently blocked as there is no active spec,
would be great if someone from the glance team could get that rolling again.

I started digging back through the patches in detail to figure out if
there are some infrastructure bits we could get in early regardless.

#1 - new methods for glance xenserver plugin

Let's take a simplified approach on this patch -
https://review.openstack.org/#/c/266933 and only change the
xenapi/etc/xapi.d/plugins/ content in the following ways.

- add upload/download_vhd_glance2 methods. Don't add an api parameter.
Add these methods mostly via copy/paste as we're optimizing for deleting
v1 not for fixing v1.

That will put some infrastructure in place so we can just call the v2
actions based on decision from higher up the stack.

#2 - move discover major version back to glanceclient -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108

I don't understand why this was ever in nova. This really should be

glanceclient.discover... something. It uses internal methods from
glanceclient and internal structures of the content returned.


FWIW, I use:

from glanceclient.common import utils as glance_utils
endpoint, detected_version = glance_utils.strip_version(endpoint)

To part of trying to figure this out as a consumer. Of course, that's 
partially because like most of the openstack clients, there is no 
exposed API for querying versions, since you have to tell the 
constructor what major version you want to construct.



Catching, if desired, should also be on the glanceclient side.
glanceclient.reset_version() could exist to clear any caching.

#3 - Ideally we'd also have a

client = glanceclient.AutoClient(endpoint, ... ) which basically does
glanceclient.discover and returns us the right client automatically.
client.version provides access to the version information if you need to
figure out what version of a client you have.


You should just do:

import os_client_config

client = os_client_config.legacy_client('image') since all of that work 
is pretty much already done.


If glanceclient grows the ability to be used without a priori knowledge 
of the version, I'll certainly start to use it  there.



This starts to get to a point where the parts of versioning that
glanceclient should know about are in glanceclient, and when nova still
needs to know things it can as for client.version.

For instance make _extract_query_params -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L448
become and instance method that can

if self._client.version >= 2:
...
else:
...


This isn't the whole story to get us home, however chunking up some of
these pieces I think makes getting the rest of the story in much
simpler. In nearly every case (except for the alt link in the image
view) we can easily have access to a real glance client. And the code
will be a ton easier to understand with some of the glanceclient
specific details behind the glanceclient interface.

-Sean




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

[openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

[Aleksandr Didenko]

Hi.

  As you may know, we're still using some very old astute.yaml fixtures
(v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have
problems with fixture-to-rspec mapping [1]. So we've started to work on
those problems [2].

  So please be aware of upcoming changes in noop rspec fixtures and tests.
If you see, that some important fixtures are missing (thus not covered by
tests) please let me know in this email thread or via IRC/email/slack.

  Also, we should stop updating astute.yaml fixtures manually and start
using some kind of automation approach instead [3][4]. I propose to use [5]
script until we find a better solution. So if you want to add some new
astute.yaml fixture for noop tests, please propose a patch to this script
instead of uploading yaml file.

Currently the following is missing in the new set of fixtures for fuel-9.0:
- generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
properly enable it via nailgun, any help is much appreciated)
- selective ssl fixtures - since configuration data is not serialized from
nailgun, I think that we should move this into 'hiera/override' along with
implementation of new hiera overrides tests workflow [6]
- vmware related fixtures

Please feel free to share your ideas/comments on this topic.

Thanks,
Alex

[0] https://bugs.launchpad.net/fuel/+bug/1535339
[1]
https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
[2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
[3]
https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
[4]
https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
[5]
https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
[6] https://bugs.launchpad.net/fuel/+bug/1564919
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Sean Dague]

The glance v2 work is currently blocked as there is no active spec,
would be great if someone from the glance team could get that rolling again.

I started digging back through the patches in detail to figure out if
there are some infrastructure bits we could get in early regardless.

#1 - new methods for glance xenserver plugin

Let's take a simplified approach on this patch -
https://review.openstack.org/#/c/266933 and only change the
xenapi/etc/xapi.d/plugins/ content in the following ways.

- add upload/download_vhd_glance2 methods. Don't add an api parameter.
Add these methods mostly via copy/paste as we're optimizing for deleting
v1 not for fixing v1.

That will put some infrastructure in place so we can just call the v2
actions based on decision from higher up the stack.

#2 - move discover major version back to glanceclient -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108

I don't understand why this was ever in nova. This really should be

glanceclient.discover... something. It uses internal methods from
glanceclient and internal structures of the content returned.

Catching, if desired, should also be on the glanceclient side.
glanceclient.reset_version() could exist to clear any caching.

#3 - Ideally we'd also have a

client = glanceclient.AutoClient(endpoint, ... ) which basically does
glanceclient.discover and returns us the right client automatically.
client.version provides access to the version information if you need to
figure out what version of a client you have.


This starts to get to a point where the parts of versioning that
glanceclient should know about are in glanceclient, and when nova still
needs to know things it can as for client.version.

For instance make _extract_query_params -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L448
become and instance method that can

if self._client.version >= 2:
   ...
else:
   ...


This isn't the whole story to get us home, however chunking up some of
these pieces I think makes getting the rest of the story in much
simpler. In nearly every case (except for the alt link in the image
view) we can easily have access to a real glance client. And the code
will be a ton easier to understand with some of the glanceclient
specific details behind the glanceclient interface.

-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] [Glance] Newton virtual pre-summit sync

[Flavio Percoco]

On 31/03/16 17:34 -0400, Nikhil Komawar wrote:

Hi all,

I'm excited to see you all Glancers at the Austin summit and discuss
more on our project.

Nevertheless, I feel that our summit conversations will have a lot more
value if we establish some prior-context to the discussions and prepare
ourselves for some of the sessions. Hence, I would like to call for a
virtual sync meetup on the week of April 11th.

My initial plan is to have a 4 hour sync on Tuesday April 12th, from
1400-1800 UTC (we can decide on the length of the sessions and the
required breaks later). But sending out this tentative plan to gauge the
feasibility and interest.


Happy to join!


Please reply to this thread with your thoughts. If none, looking forward
to seeing you at the event.

P.S. based on the number of interested participants we can decide on the
tool to be used.



We can use my bluejeans bridge. It work fairly well for the virtual mid-cycle we
did a couple of months ago.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

[Oleg Gelbukh]

Bogdan,

I mostly agree with you on this. The only data that might originate from a
node is discovery-related parameters, like CPU/disks/NICs architecture and
such.

However, at the moment the deployment data is partially generated at every
node (i.e. globals.yaml, override/plugins/* and some other files) and is
not exposed in any way externally. But since this data is required to
integrate with 3rd-party configuration management tools, we create an
interim solution to make them available 'as is'.

This situation should change in the next few months, and then nodes shall
be moved to purely consumer role in the deployment data pipeline.

--
Best regards,
Oleg Gelbukh

On Fri, Apr 1, 2016 at 1:37 PM, Bogdan Dobrelya 
wrote:

> On 04/01/2016 10:41 AM, Oleg Gelbukh wrote:
> > Andrew,
> >
> > This is an excellent idea. It is apparently more efficient and
> > error-proof to make the split not by the resulted data but at the time
> > it is actually generated. We will play with this idea a little bit, and
> > will come up with design proposal shortly.
> >
> > Meanwhile, please be informed that we already started testing the
> > solution based on the node-level data exposed via ConfigDB API extension
> > for Nailgun [1] [2]. I will keep you updated on our progress in that
> area.
>
> I strongly believe that nodes must only consume data, not provide one.
> And the data must be collected from its sources, which is Nailgun API
> extensions, like Andrew described.
>
> >
> > [1] Specification for Nailgun API for serialized facts
> > 
> > [2] Spec for upload of deployment configuration to ConfigDB API
> > 
> >
> > --
> > Best regards,
> > Oleg Gelbukh
> >
> > On Thu, Mar 31, 2016 at 11:19 PM, Andrew Woodward  > > wrote:
> >
> > One of the problems we've faced with trying to plug-in ConfigDB is
> > trying to separate the cluster attributes from the node attributes
> > in the serialized output (ie astute.yaml)
> >
> > I started talking with Alex S about how we could separate them after
> > astute.yaml is prepared trying to ensure which was which we came
> > back uncertain that the results would be accurate.
> >
> > So I figured I'd go back to the source and see if there was a way to
> > know which keys belonged where. It turns out that we could solve the
> > problem in a simpler and more precise way than cutting them back
> > apart later.
> >
> > Looking over the deployment_serializers.py [1] the serialized data
> > follows a simple work flow
> >
> > iterate over every node in cluster
> >   if node is customized:
> > serialized_data = node.replaced_deployment_data
> >   else:
> > serialized_data = dict_merge(
> >   serialize_node(node),
> >   get_common_attrs(cluster))
> >
> > Taking this into mind, we can simply construct an extension to
> > expose these as an APIs so that we can consume them as a task in the
> > deployment graph.
> >
> > Cluster:
> > We can simply expose
> > DeploymentMultinodeSerializer().get_common_attrs(cluster)
> >
> > This would then be plumbed to the cluster level in ConfigDB
> >
> > Node:
> > if a Node has customized data, then we can return that at the node
> > level, this continues to work at the same as native since it most
> > likely has Cluster merged into it.
> >
> > otherwise we can return the serialized node with whichever of the
> > first 'role' the node has
> >
> > We would expose DeploymentMultinodeSerializer().serialize_node(node,
> > objects.Node.all_roles(node)[0])
> >
> > for our usage, we don't need to worry about the normal node role
> > combination as the data only influences 'role' and 'fail_if_error'
> > attributes, both are not consumed in the library.
> >
> >
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121
> > --
> >
> > --
> >
> > Andrew Woodward
> >
> > Mirantis
> >
> > Fuel Community Ambassador
> >
> > Ceph Community
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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,
> Bogdan Dobrelya,
> Irc 

[openstack-dev] [nova] the bugs team needs (more) members

[Markus Zoeller]

TL;DR: * The Nova bugs team needs more members
   * Tasks: https://wiki.openstack.org/wiki/BugTriage
   * Cleanup: http://45.55.105.55:8082/bugs-dashboard.html
   * Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
   * Etherpad: https://etherpad.openstack.org/p/nova-bugs-team


The Nova project has a large backlog of open bug reports. Around 5 new
bug reports get created everyday. It is not possible to make a 
reasonable progress with the current number of people. The nova bugs
team needs to play a more active role and it needs more people for that.


What's in for you?
--
As bugs are in every software in every place, you will get around a lot.
Having a specific issue makes it also easier to ping other folks to
discuss this issue. Bug fixes also don't have the hard deadlines 
imposed on feature patches. Being once on the bug triage side will
improve the quality of your future bug reports which will make them
more likely to get solved.


Current Status
--
The main issue which slows down all following steps are bug reports
without the essential informations [1]:
* versions (nova, hypervisor, database, ...) 
* steps-to-reproduce (with actual data)
* expected behavior 
* actual observed behavior
* logs (in debug mode)
* topology (for example: nova-network vs. neutron)
Although this gets asked for when creating a bug report, the vast
majority of bug reports lack this information. Usually it takes one
to three roundtrips to get this information from the reporter. This
is time consuming. As we focus less on new features in Newton [2] I 
have the hope that the bug list will get more attention.


Tasks
-
The tasks are listed in the wiki [3]. They "just" need to be done.
Repeatedly. Some on a daily basis, some less frequently. The cleanup
dashboard [4] is a tool I use personally but can be used by you too.

The Neutron folks introduced a weekly rotating bug skimming duty and
they've made good experiences with it. This involves 1-3 people who
check new bugs reports if they are valid and provide the essential
information. We should adapt that [5].

In general we should aim for:
* respond to new bugs in a timely manner to get high quality reports
* clean up the "old stuff" (>= 1.5 years)
* spread the effort to multiple shoulders
* rotate the different efforts to prevent exhaustion and tunnel vision

There is an ongoing effort to move the RFEs (request for feature 
enhancements) away from the bug list [6] to allow us to be more
focused on faulty behavior of existing features people already rely on.


Organization

* The nova bugs team has an IRC meeting [7] which allows us to sync
  with each other.
* The cleanup dashboard [4] shows bug reports which need a check
  based on the tasks [3].
* The etherpad [8] can be used to avoid an overlap of efforts of
  different people.


Education
-
It's possible to use the nova bugs team IRC meeting for education 
sessions if this helps you.
I will also attend the summit in Austin in a few weeks. We can do an
unofficial "bugs mgmt process" crash course there if you like. Just
talk to me there (or beforehand in IRC) and we will find the time 
and space.
At last I can offer a Google Hangout session if some are interested
in that.


How to Join?

* Join the nova-bugs Launchpad group [9]
* Familiarize with the process [10]
* Attend the bugs meeting [7]

With a few people who are willing to spent a few hours per week we
can create a well maintained bug list where issues get addressed
in a timely manner to consistently improve the quality of Nova.


References
--
[1] "working on bug reports; what blocks you?": 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089677.html
[2] "No spec approvals for new things until after the summit": 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html
[3] https://wiki.openstack.org/wiki/BugTriage
[4] http://45.55.105.55:8082/bugs-dashboard.html
[5] 
https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
[6] "Wishlist bugs == (trivial) blueprint?": 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html
[7] https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
[8] https://etherpad.openstack.org/p/nova-bugs-team
[9] https://launchpad.net/~nova-bugs
[10] http://markuszoeller.github.io/posts/2015/12/01/openstack-bugs/


Regards, Markus Zoeller (markus_z) 


__
OpenStack Development Mailing 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][ConfigDB] Separating node and cluster serialized data

[Bogdan Dobrelya]

On 04/01/2016 10:41 AM, Oleg Gelbukh wrote:
> Andrew,
> 
> This is an excellent idea. It is apparently more efficient and
> error-proof to make the split not by the resulted data but at the time
> it is actually generated. We will play with this idea a little bit, and
> will come up with design proposal shortly.
> 
> Meanwhile, please be informed that we already started testing the
> solution based on the node-level data exposed via ConfigDB API extension
> for Nailgun [1] [2]. I will keep you updated on our progress in that area.

I strongly believe that nodes must only consume data, not provide one.
And the data must be collected from its sources, which is Nailgun API
extensions, like Andrew described.

> 
> [1] Specification for Nailgun API for serialized facts
> 
> [2] Spec for upload of deployment configuration to ConfigDB API
> 
> 
> --
> Best regards,
> Oleg Gelbukh
> 
> On Thu, Mar 31, 2016 at 11:19 PM, Andrew Woodward  > wrote:
> 
> One of the problems we've faced with trying to plug-in ConfigDB is
> trying to separate the cluster attributes from the node attributes
> in the serialized output (ie astute.yaml)
> 
> I started talking with Alex S about how we could separate them after
> astute.yaml is prepared trying to ensure which was which we came
> back uncertain that the results would be accurate.
> 
> So I figured I'd go back to the source and see if there was a way to
> know which keys belonged where. It turns out that we could solve the
> problem in a simpler and more precise way than cutting them back
> apart later.
> 
> Looking over the deployment_serializers.py [1] the serialized data
> follows a simple work flow
> 
> iterate over every node in cluster
>   if node is customized:
> serialized_data = node.replaced_deployment_data
>   else:
> serialized_data = dict_merge(
>   serialize_node(node),
>   get_common_attrs(cluster))
> 
> Taking this into mind, we can simply construct an extension to
> expose these as an APIs so that we can consume them as a task in the
> deployment graph.
> 
> Cluster:
> We can simply expose
> DeploymentMultinodeSerializer().get_common_attrs(cluster)
> 
> This would then be plumbed to the cluster level in ConfigDB
> 
> Node:
> if a Node has customized data, then we can return that at the node
> level, this continues to work at the same as native since it most
> likely has Cluster merged into it.
> 
> otherwise we can return the serialized node with whichever of the
> first 'role' the node has
> 
> We would expose DeploymentMultinodeSerializer().serialize_node(node,
> objects.Node.all_roles(node)[0])
> 
> for our usage, we don't need to worry about the normal node role
> combination as the data only influences 'role' and 'fail_if_error'
> attributes, both are not consumed in the library.
> 
> 
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121
> -- 
> 
> --
> 
> Andrew Woodward
> 
> Mirantis
> 
> Fuel Community Ambassador
> 
> Ceph Community
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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,
Bogdan Dobrelya,
Irc #bogdando

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

[openstack-dev] [nova] Reminder: Next scheduler sub team meeting

[Chris Dent]

The next nova scheduler sub team meeting will be Monday, 4th April
at 14:00 UTC.

The agenda is at:
https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting

If you have something you'd like to discuss, please add to the
agenda.

Thanks.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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]: Neutron naming legal issues

[Maish Saidel-Keesing]

On 04/01/16 12:38, Ihar Hrachyshka wrote:
> Alexander Kostrikov  wrote:
>
>> What about Netrone?
>
> That could be a good one but it may also be a violation:
> http://www.infomoby.et/en/profile/netrone_networks_plc/64213
>
> One idea I had in my mind for a while is using some alternative
> alphabet for project naming. Ideally for some language that is not so
> popular as English. In case of Neutron, a name like ‘Нетронь’ could be
> a good fit and would even better reflect maturity the project achieved
> throughout all those years, iykwim.
I can almost guarantee that if you use Hebrew letters then it will be a
safe bet.
ניוטרון
But on the other hand - no-one would know how to read/pronounce it
:)
>
> Ihar
>
> __
>
> OpenStack Development Mailing 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,
Maish Saidel-Keesing

__
OpenStack Development Mailing 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] [magnum] Proposing Eli Qiao for Magnum core reviewer team

[Spyros Trigazis]

+1

I'm a new contributor, but Eli made already a
good impression on me.

Cheers,
Spyros

On 1 April 2016 at 10:51, Cammann, Tom  wrote:

> +1
>
> From: Hongbin Lu 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, 31 March 2016 at 19:18
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core
> reviewer team
>
> Hi all,
>
> Eli Qiao has been consistently contributed to Magnum for a while. His
> contribution started from about 10 months ago. Along the way, he
> implemented several important blueprints and fixed a lot of bugs. His
> contribution covers various aspects (i.e. APIs, conductor, unit/functional
> tests, all the COE templates, etc.), which shows that he has a good
> understanding of almost every pieces of the system. The feature set he
> contributed to is proven to be beneficial to the project. For example, the
> gate testing framework he heavily contributed to is what we rely on every
> days. His code reviews are also consistent and useful.
>
> I am happy to propose Eli Qiao to be a core reviewer of Magnum team.
> According to the OpenStack Governance process [1], we require a minimum of
> 4 +1 votes within a 1 week voting window (consider this proposal as a +1
> vote from me). A vote of -1 is a veto. If we cannot get enough votes or
> there is a veto vote prior to the end of the voting window, Eli is not able
> to join the core team and needs to wait 30 days to reapply.
>
> The voting is open until Thursday April 7st.
>
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> 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 Development Mailing 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]: Neutron naming legal issues

[Ihar Hrachyshka]

Alexander Kostrikov  wrote:


What about Netrone?


That could be a good one but it may also be a violation:  
http://www.infomoby.et/en/profile/netrone_networks_plc/64213


One idea I had in my mind for a while is using some alternative alphabet  
for project naming. Ideally for some language that is not so popular as  
English. In case of Neutron, a name like ‘Нетронь’ could be a good fit and  
would even better reflect maturity the project achieved throughout all  
those years, iykwim.


Ihar

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