Re: [openstack-dev] [release][ansible][fuel][kolla][puppet][tripleo] proposed deadlines for cycle-trailing projects

[Steven Dake (stdake)]

Doug,

We have already tagged rc1 long ago, but ack on rc2 (we are targeting 12th at 
present) and ack on 20th for retag of  final rc.  We expect our rc2 to be final.

If there are critical bugs that make the release doa in some way (such as 
upgrades, reconfigure etc), we will obviously have to tag an rc3 to then retag 
that as final.  I don’t expect that to happen but it is a possibility.

Regards
-steve


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

Date: Friday, October 7, 2016 at 12:16 PM
To: openstack-dev 
Subject: [openstack-dev] [release][ansible][fuel][kolla][puppet][tripleo] 
proposed deadlines for cycle-trailing projects

This week we tagged the final releases for projects using the
cycle-with-milestones release model. Projects using the cycle-trailing
model have two more weeks before their final release tags are due. In
the time between now and then, we expect those projects to be preparing
and tagging release candidates.

Just as with the milestone-based projects, we want to manage the number,
frequency, and timing of release candidates for cycle-trailing projects.
With that in mind, I would like to propose the following rough timeline
(my apologies for not preparing this sooner):

10 Oct -- All cycle-trailing projects tag at least their first RC.
13 Oct -- Soft deadline for cycle-trailing projects to tag a final RC.
18 Oct -- Hard deadline for cycle-trailing projects to tag a final RC.
20 Oct -- Re-tag the final RCs as a final release.

Between the first and later release candidates, any translations and
bug fixes should be merged.

We want to leave a few days between the last release candidate and
the final release so that downstream consumers of the projects can
report issues against stable artifacts. Given the nature of most
of our trailing projects, and the lateness of starting to discuss
these deadlines, I don't think we need the same amount of time as
we usually set aside for the milestone-based projects. Based on
that assumption, I've proposed a 1 week soft goal and a 2 day hard
deadline.

Let me know what you think,
Doug

Newton schedule: https://releases.openstack.org/newton/schedule.html

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

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

Re: [openstack-dev] [Neutron] ARP spoofing in VLAN aware VMs

[Bence Romsics]

Hi Kuba,

On Fri, Sep 30, 2016 at 3:38 PM, Jakub Libosvar  wrote:
> The issue was with subports having different MAC addresses
> than MAC address of the parent port. Packets leaving virtual instance via
> VLAN interfaces (e.g. eth0.1) have always source MAC address of VLAN parent
> interface (e.g. eth0).

Despite that being the default behavior do you consider that valid
use? I mean I would consider either (a) valid or (b) valid, but not
their combinations:

(a)
create port0
create port1 with same mac
create trunk with parent port0 and subport port1
boot instance with port0
bring up subport vlan interfaces only specifying vlan ids

(b)
create port0
create port1 with autoallocated (almost always different) mac
create trunk with parent port0 and subport port1
boot instance with port0
bring up subport vlan interfaces specifying vlan ids *and mac addresses*

Cheers,
Bence

ps. For being more specific please see the beginning of this CLI
example: https://wiki.openstack.org/wiki/Neutron/TrunkPort#CLI_usage_example

__
OpenStack Development Mailing 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][placement] placement newton leftovers

[Chris Dent]

On Sun, 2 Oct 2016, Chris Dent wrote:


I'm posting this as it would be great to get some feedback on:

* which of these things matter
* what is missing from the list
* how (or if) we should formalize the doing of the work
* who would like to help out in the doing (getting some help is the main
 goal, all the rest of is set up)


Based on conversation in IRC: To facillitate other people getting
involved I've duplicated my original message to an etherpad, made some
light formatting adjustments and added a couple more links:

https://etherpad.openstack.org/p/placement-newton-leftovers

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://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][Nova] Expose trunk details over metadata API

[Bence Romsics]

Hi,

To follow up on the complications of bringing up trunk subports [1] I
have written up a small proposal for a tiny new feature affecting
neutron and nova. That is how to expose trunk details over metadata
API. To avoid big process overhead I have opened a newton rfe ticket
[2], plus a nova specless blueprint [3] pointing to it. Please let me
know if I should have followed a different process.

Cheers,
Bence

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104848.html
[2] https://bugs.launchpad.net/neutron/+bug/1631371
[3] https://blueprints.launchpad.net/nova/+spec/trunk-details-meta

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

[openstack-dev] [Glance] [stable] Bug backports

[Ian Cordasco]

Hi Glancers!

After the news that we all released Newton yesterday, it's time to
start thinking about backports the future of our Mitaka and Liberty
branches.

I expect that Mitaka will start to enter Phase II [1] and Liberty's
end-of-life is right around the corner [2] (2016-11-17). If there are
bugs that are affecting those branches that need to be backported
before their status changes, they should be proposed immediately and
brought up at the Glance team meeting [3].

[1]: http://docs.openstack.org/project-team-guide/stable-branches.html
[2]: https://releases.openstack.org/
[3]: http://eavesdrop.openstack.org/#Glance_Team_Meeting

Cheers!
--
Ian Cordasco

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

[openstack-dev] [glance] priorities for the next two weeks

[Brian Rosmaita]

I'd like to reiterate what we discussed during the "Core Awareness" topic
at yesterday's Glance weekly meeting for those who weren't able to attend
or read through the meeting logs yet.

Three Ocata priorities have already been determined:
(1) image import refactor
(2) community images (including image 'visibility' enhancements)
(3) rolling upgrades, specifically the database strategy for zero-downtime
upgrades

There's a sub-team working on image import (weekly sync in
#openstack-glance at 14:00 UTC).

Any cores not working on image import, please direct your attention to
community images:
- https://review.openstack.org/369110

- https://review.openstack.org/366354
- https://review.openstack.org/379852
With timely reviews, we may be able to land this before the summit.
Additionally, it's important to have the code merged so for the sub-team
working on rolling upgrades, so they can demonstrate how the strategy will
work on a real-life migration.

As far as rolling upgrades reviews go, there are a lot of comments on the
database strategy spec, but not many of these are from Glance cores.  It
would be good to take a look to sanity check the strategy being proposed:
- https://review.openstack.org/#/c/331740/
Additionally, there's a patch for moving db migrations from
SQLAlchemy-migrate to Alembic:
- https://review.openstack.org/#/c/374278/
And a patch up to make the switch to Alembic:
- https://review.openstack.org/#/c/382958/
Please take the time to look these over.  If you have reservations about
the move to Alembic, now's the time to make them heard.

So, those are the Glance priorities for the next two weeks.

cheers,
brian


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

Re: [openstack-dev] [cinder] How to retrieve volume_driver

[Jay S. Bryant]

On 10/07/2016 12:10 PM, Sean McGinnis wrote:

On Fri, Oct 07, 2016 at 05:04:00PM +0200, cr...@interia.pl wrote:

Hi Erlon.

Thank you for the reply. I need to collect this information to generate sort of 
overview of drivers used in given environment. Obviously, it potentially is a 
multiple backed one. This information does not need to be pulled from the 
cinder API - I can assume I work under root on host on which cinder service is 
running.

Parsing of cinder.conf comes with usual problems related to trying to get 
runtime information from config file. It is very prone to suddenly stop working 
due to changes in OpenStack itself. We may also potentially run into a 
situation in which config file has been modified, but Cinder has not been 
restarted (or worse, file is currently being edited and we read garbage). Now, 
if it comes to that I can live with those problems, but I was hoping a cleaner 
solution exists (as mentioned earlier - volume_backend_name, defined in same 
config, is very easy to retrieve).

Thanks again and best regards,
Lukasz


This type of information is not exposed via the API, since this is a
configuration detail that someone interacting with a cloud should not
have access to.

The format of cinder.conf does not change much, so grepping for the line
that starts with "volume_driver = " should be a very safe assumption to
make.

That does not address the case you mentioned of the cinder.conf possibly
being changed but the service not restarted yet. I think that's probably
a very low risk, but the only way I can think of to get around that is
to grep the current state out of the c-vol.log file. That would bring
with it many more risks though. There's not a standard location or even
name for that log file. And it's quite possible the volume drivers did
change, the service was restarted, but there's still a volume_driver
mentioned in the log that is not in fact used any more.

And it would also need to assume DEBUG level logging was enabled. So
really I think grep'ing cinder.conf is your best bet here.

Sean (smcginnis)

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


As Sean states the cinder.conf file format has been stable for quite 
some time.  So, I don't think you need to worry about volume_driver 
changing any time soon.


If you wanted an additional level of reassurance that you are getting 
the right information you could check the number of c-vol processes 
running on the system to ensure it matches the number of volume_driver 
's specified in the config file.  I think that it would be a rare case 
where the user is swapping one backend for another.  More likely to see 
additive/subtractive changes.  So, you could give yourself some 
confidence by checking those numbers and comparing.  Flagging when they 
don't match.


Jay


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

Re: [openstack-dev] [nova] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

[Matt Riedemann]

On 10/6/2016 7:58 AM, Kashyap Chamarthy wrote:

On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote:

TL;DR
-

From the debug analysis of the log below, and discussion with Eric Blake
of upstream QEMU / libvirt resulted in the below bug report:

  https://bugzilla.redhat.com/show_bug.cgi?id=1382165 --
  virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the
  "ready" field of `query-block-jobs`


When I raised this on libvirt mailing list[0][1], one of the upstream
libvirt devs expressed an NACK in adjusting / "deliberately reporting
false data in block info structure".  Similar concern was also shared by
Matt Booth on #openstack-nova IRC.

Next, turns out the READY event is already exposed via the guest XML[1]:

-
We expose the state of the copy job in the XML and forward the READY
event from qemu to the users.

A running copy job exposes itself in the xml as:


  
  
  
  


  
  [...]


While the ready copy job is exposed as:


  
  
  
  


  
  [...]



Additionally we have anyncrhronous events that are emitted once qemu
notifies us that the block job has reached sync state or finished.
Libvirt uses the event to switch to the ready state.

The documentation suggests that block jobs should listen to the events
and act accordingly only after receiving the event.
-

So, Nova's is_job_complete() method & friends need to be reworked to
listen on the events for job readiness.

[0]
https://www.redhat.com/archives/libvir-list/2016-October/msg00217.html
[1] https://www.redhat.com/archives/libvir-list/2016-October/msg00229.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1382165#c3



Details
---

The code in Nova that's being executed is this part in _swap_volume()
from libvirt/driver.py.

[...]
# Start copy with VIR_DOMAIN_REBASE_REUSE_EXT flag to
# allow writing to existing external volume file
dev.rebase(new_path, copy=True, reuse_ext=True)

while not dev.is_job_complete():
time.sleep(0.5)


dev.abort_job(pivot=True)
[...]



[...]



Thanks for the great libvirtd log analysis, that's really helpful see 
what's going on and where we fail.


I've replied in Matthew's patch, which I think we can get in now 
regardless and backport.


As for the fix, it sounds like mdbooth is going to work on the event 
listener code, which I'm hesitant to backport, but honestly this is such 
a latent broken flow that I don't think we really need to backport any 
fixes, at least for the event listener work to fix this long-term. The 
swap-volume test is disabled by default in Tempest and we enable it in 
devstack, so we can control which CI environments it runs in.


--

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] FYI, nova plans to have a room at the PTG in February

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2016-10-07 10:20:51 +0200:
> Doug Hellmann wrote:
> > Excerpts from Matt Riedemann's message of 2016-10-06 13:52:09 -0500:
> >> Sorry yeah I screwed that up. I re-read the PTG email and the first two 
> >> days are cross-project things, and Wed-Fri are meetup style at the PTG, 
> >> it's not time-boxed sessions like the design summit, unless again I'm 
> >> screwing this up and this is just a thing that's not explainable to mere 
> >> mortals until we actually experience one.
> > 
> > It's not fully time-boxed, but as Clint pointed out it might be
> > useful to establish some sort of estimated schedule so cross-team
> > discussions can be coordinated.
> 
> The first two days are for horizontal teams and cross-project effort
> participants to meet. Those are *not* 40-min timeboxed fishbowl
> discussions, each room will be dedicated to a given effort for two full
> days.
> 
> That said, to facilitate having critical discussions, we'll set up some
> system to announce that a specific discussion will happen at a specific
> time. Open to options here (could be low-tech like mailing-list or
> whiteboard, high-tech with some specific webapp), but the idea would be
> to be able to easily find out when you should probably go out of your
> team room and join another.
> 

My hope was that it would be "the summit without the noise". Sounds like
it will be "the summit without the noise, or the organization".

I'd really like to see time boxes for most if not all of it, even if many
of the boxes are just half a day of "work time" which means "we want to
work on stuff together without the overhead of less involved participants."

The two days of cross project is awesome. But there are also big
single-project initiatives that have cross-project interest anyway.

For instance, the movement of the scheduler out of Nova is most definitely
a Nova session, but it has ramifications for oslo, performance, neutron,
cinder, architecture, API-WG, etc.  etc. If we don't know when Nova is
going to discuss it, how can we be there to influence that discussion?

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

Re: [openstack-dev] [cinder] How to retrieve volume_driver

[Sean McGinnis]

On Fri, Oct 07, 2016 at 05:04:00PM +0200, cr...@interia.pl wrote:
> Hi Erlon. 
> 
> Thank you for the reply. I need to collect this information to generate sort 
> of overview of drivers used in given environment. Obviously, it potentially 
> is a multiple backed one. This information does not need to be pulled from 
> the cinder API - I can assume I work under root on host on which cinder 
> service is running. 
> 
> Parsing of cinder.conf comes with usual problems related to trying to get 
> runtime information from config file. It is very prone to suddenly stop 
> working due to changes in OpenStack itself. We may also potentially run into 
> a situation in which config file has been modified, but Cinder has not been 
> restarted (or worse, file is currently being edited and we read garbage). 
> Now, if it comes to that I can live with those problems, but I was hoping a 
> cleaner solution exists (as mentioned earlier - volume_backend_name, defined 
> in same config, is very easy to retrieve). 
> 
> Thanks again and best regards,
> Lukasz
> 

This type of information is not exposed via the API, since this is a
configuration detail that someone interacting with a cloud should not
have access to.

The format of cinder.conf does not change much, so grepping for the line
that starts with "volume_driver = " should be a very safe assumption to
make.

That does not address the case you mentioned of the cinder.conf possibly
being changed but the service not restarted yet. I think that's probably
a very low risk, but the only way I can think of to get around that is
to grep the current state out of the c-vol.log file. That would bring
with it many more risks though. There's not a standard location or even
name for that log file. And it's quite possible the volume drivers did
change, the service was restarted, but there's still a volume_driver
mentioned in the log that is not in fact used any more.

And it would also need to assume DEBUG level logging was enabled. So
really I think grep'ing cinder.conf is your best bet here.

Sean (smcginnis)

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

Re: [openstack-dev] [Neutron][Nova] Expose trunk details over metadata API

[Bence Romsics]

Jay, let me correct myself. After a round of discussion with Armando
I'm no longer sure exactly what nova changes would be needed. The
discussion went into a direction where we started to question which
part of the change should fall into neutron and which part into nova.
I think joint nova-neutron design would be beneficial to avoid a
ping-pong between the projects. So far the discussion lacks the
opinions of nova developers. It would be welcome:
https://bugs.launchpad.net/neutron/+bug/1631371

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

[Eric K]

Thanks for the additional notes, Thierry!

On 10/6/16, 12:53 AM, "Thierry Carrez"  wrote:

>Good summary. It is true that for small-to-medium sized teams (which did
>not routinely organize midcycles), there is a tough choice to make.
>
>See a couple of remarks inline:
>
>Eric K wrote:
>> Here are some of our choices as a team, as well as some first thoughts
>>on
>> pros and cons:
>> 
>> 1. Do work sessions at PTGs; no organized work sessions at summits.
>> Pro: schedule lines up wit beginning of dev cycle
>> Pro: work room available
>> Pro: easy to collaborate with other teams
>> Con: extra travel for those who will continue to attend summit.
>
>+Pro: PTGs are organized in cheaper locations and closer to the center
>of mass of contributors, hopefully making it less costly to travel to
>overall
>+Pro: More team time (for Congress: 2-3 days instead 2-3 hours) for a
>better return on travel investment
>
>> 2. Unofficial work session at summits; no work sessions at PTGs.
>> Pro: For people who would be going to the summits anyway, this option
>> reduces travel.
>> Con: probably no official work room available.
>> Con: happens at the middle of a dev cycle
>> 
>> 3. Separately organize work sessions in the style of past mid-cycle
>> sprints; no work sessions at any of the official openstack events.
>> Pro: we can choose schedule and location
>> Con: harder to collaborate with other teams
>
>+Con: extra travel for those who will continue to attend summit
>
>-- 
>Thierry Carrez (ttx)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing 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-docs] Admin guide in-tree?

[Jay Faulkner]

I'm not necessarily just asking for it to be done -- I'm curious what the scope 
of work is because I'm potentially willing to help (and find folks to help) get 
it done sooner. If the docs team does not support the admin guide in-tree until 
Pike, It'll be Q or later before other projects can utilize it. That's over a 
year from today, and I'd rather not have to wait that long to get a better 
admin guide up for Ironic.

Thanks,
Jay Faulkner
OSIC

> On Oct 6, 2016, at 8:04 PM, Lana Brindley  wrote:
> 
> (Adding the dev list to cc, as I think this conversation deserves a wider 
> audience)
> 
> Thanks for this feedback. I'm really glad that the new Install Guide model is 
> working out well for people!
> 
> Since our new Install Guides have only just been published, at this stage I'm 
> intending to gather some data on how projects and users are using the 
> project-specific Install Guides during the next cycle. I'm also intending to 
> spend some time in the Ocata cycle on improving that index page. It's pretty 
> ugly right now, and I think there's some  serious UX improvements to be done. 
> Since Ocata is a short cycle, I'm also conscious of how much the docs team 
> might realistically be able to achieve.
> 
> All that said, you are certainly not the first to ask if this model can be 
> extended! I think it's something that the docs community would like to see, 
> and it seems as though it has broad support amongst developers and projects 
> as well. So, in short, I think this is a thing that will happen, but probably 
> not in Ocata. I'm tentatively willing to tell you that Pike is a possibility 
> though ;)
> 
> Lana
> 
> On 07/10/16 12:43, Steve Martinelli wrote:
>> FWIW, the keystone team would also be interested in this model
>> 
>> On Thu, Oct 6, 2016 at 11:40 AM, Jay Faulkner > > wrote:
>> 
>>Hi all,
>> 
>>For those of you who don't know me, I'm Jay Faulkner and I work on Ironic 
>> as the Docs liaison as one of my hats.
>> 
>>Ironic launched our install-guide right after newton closed, and 
>> backported it, thanks to the changes to make the install-guide available in 
>> tree. We're a huge fan of this model, and I'm curious if there's any plans 
>> to make this happen for the admin-guide. If not, can someone help me 
>> understand the scope of work, presuming it's something that the docs group 
>> is interested in.
>> 
>>If we can get the technical infrastructure in place to do admin-guide in 
>> tree, I'd expect Ironic to quickly adopt it, like we did for the install 
>> guide.
>> 
>>Thanks,
>>Jay Faulkner
>>OSIC
>> 
>> 
>>___
>>OpenStack-docs mailing list
>>openstack-d...@lists.openstack.org 
>> 
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs 
>> 
>> 
>> 
>> 
>> 
>> ___
>> OpenStack-docs mailing list
>> openstack-d...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>> 
> 
> --
> Lana Brindley
> Technical Writer
> Rackspace Cloud Builders Australia
> http://lanabrindley.com
> 
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



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

Re: [openstack-dev] [tripleo] Getting the UI to talk with Undercloud API service endpoints

[Dan Trainor]

Hi -

Great suggestions, Dan.

To recap, we followed that up with a few other ideas on irc and we
eventually came to a point to test some of this, with slight modification.

UI also ships with a configuration file that can override the endpoint
information received from Keystone.  The file is located
at /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js.

Part of making this work means enabling SSL on the Undercloud when the UI
component is selected for installation in undercloud.conf.  I think this is
going to be a pretty reasonable request, but I'm interested in hearing
feedback from this, and what other implications it may have, that I can't
think of.  The changes I made were all one-off, unmanaged changes, just to
test this idea out.  I'll be doing some more tests but will probably be
looking for acceptance shortly.

Once SSL was enabled on the Undercloud, I made two edits to haproxy.cfg
that were pretty straightforward:  added a 'listen' server directive for UI
to both terminate SSL and forward the request to Apache, and added a 'bind'
statement for each service that UI expects to talk to (keystone, heat,
ironic, mistral, swift, zaqar-websocket).

Once those configuration changes were made, I had a very pleasant
experience using the UI.  It worked exactly as expected.  I think this
might be a viable option.

Thoughts?

Thanks!
-dant






On Fri, Sep 30, 2016 at 12:21 PM, Dan Sneddon  wrote:

> Thinking about this a little more, creating a new unified endpoint on the
> same port as the UI doesn't solve the problem at hand. The UI will use the
> service catalog to find endpoints, so we would need to change the endpoints
> in the service catalog, which changes the flow for the underlying services
> as well.
>
> Simply moving the control plane services to the external network won't
> work well in environments where the control plane is isolated and
> non-routed. The Undercloud can forward packets, but then becomes a
> bottleneck and a SPOF.
>
> A few approaches come to mind, but none of these are quick fixes:
>
> * Change the UI to get its list of endpoints from somewhere other than the
> service catalog and customize this with URLs that point to the Public VIP.
> Duplicate the services required for the UI on both control plane and
> external network. This might make it possible to make all connections over
> port 443, which is more firewall-friendly (which would be desirable or not
> depending on what kind of firewalling and traffic management is wanted).
>
> * Relax the rp_filter settings on the Controllers so they accept packets
> destined for the external network on their control plane interfaces; add a
> static route to the Public VIP via the control plane VIP on all
> non-controller nodes. Modify the service catalog to point to the public VIP
> for the services the UI needs. This would need to be combined with a
> security review to determine if additional iptables rules are required.
>
> * Split the service catalog, so we have an internal and an external view
> depending on where the query came from. I'm not sure how feasible this is.
>
> Of these, I think the rp_filter settings are the only ones that could be
> done solely with TripleO code changes. That might be worth investigating.
>
> Dan Sneddon  |  Principal OpenStack Engineer  |  dsned...@redhat.com
>
>
> On Sep 30, 2016, at 11:36 AM, Dan Sneddon  wrote:
>
> I don't think we can rely on the Undercloud as an API proxy unless we
> address the lack of HA on the Undercloud.
>
> Wouldn't this be better implemented as as a single, name-based HAProxy
> instance running SSL on port 443 on the overcloud Public VIP? Then we could
> have the same endpoint for Horizon and every other API.
>
> I actually implemented this scheme in Havana before I joined Red Hat. At
> the time, we had to have a complex HAProxy config and patch the end points
> to support name-based URLs. I think some work has been done in OpenStack
> now to support this model, but I'm not sure where it stands.
>
> Dan Sneddon  |  Principal OpenStack Engineer  |  dsned...@redhat.com
>
>
> On Sep 30, 2016, at 9:44 AM, Dan Trainor  wrote:
>
> Hi -
>
> I re-read your email a few times and like a few of the things that I see,
> but I'd love some more clarification.  As I read it, a few of these things
> conflict.  I believe you're suggesting that we don't make these services
> listen on a public interface due to security concerns (and of course,
> enabling SSL would break this because haproxy would listen on these
> interfaces/ports), but this approach would be acceptable if HAProxy was
> listening on these ports, terminating SSL, and sending them to each
> respective service backend.  Am I correct i understanding this?
>
> Are you suggesting that these endpoint ports would still be externally
> accessible on the primary (public) interface of the Undercloud, but just
> managed by HAProxy?  I think that's an acceptable 

Re: [openstack-dev] [cinder] How to retrieve volume_driver

[crow1]

Hi Erlon. 

Thank you for the reply. I need to collect this information to generate sort of 
overview of drivers used in given environment. Obviously, it potentially is a 
multiple backed one. This information does not need to be pulled from the 
cinder API - I can assume I work under root on host on which cinder service is 
running. 

Parsing of cinder.conf comes with usual problems related to trying to get 
runtime information from config file. It is very prone to suddenly stop working 
due to changes in OpenStack itself. We may also potentially run into a 
situation in which config file has been modified, but Cinder has not been 
restarted (or worse, file is currently being edited and we read garbage). Now, 
if it comes to that I can live with those problems, but I was hoping a cleaner 
solution exists (as mentioned earlier - volume_backend_name, defined in same 
config, is very easy to retrieve). 

Thanks again and best regards,
Lukasz

Użytkownik "Erlon Cruz"  napisał(a): 
> Temat: Re: [openstack-dev] [cinder] How to retrieve volume_driver
> Data: 2016-10-07 14:19
> Nadawca: "Erlon Cruz" 
> Adresat: "OpenStack Development Mailing List (not for usage questions)" 
> ; 
> 
> Hi Luzasz, 
> This information (volume_driver) is only used on driver loading so, its not 
> available outside Cinder context. Can you tell how and why you need that? And 
> why parsing the conf file is not enough for you?
> Erlon
> On Fri, Oct 7, 2016 at 9:05 AM,  cr...@interia.pl wrote:
> Dear all.
> 
> 
> I'm a PHD student from Poland and have found out about this list from 
> Openstack wiki. Could you kindly tell me, if there is a way to retrieve, from 
> outside of OpenStack code, volume_driver for given backend? Preferably - 
> without a need to parse the cinder.conf file?
> 
> 
> It is fairly easy to retrieve the volume_backend_name, which in most 
> scenarios seems to describe the driver type used. However, in general 
> scenario, this is just a custom string entered by the admin. I would greatly 
> appreciate, if someone could point me to a way to acquire the unique stirng, 
> identifying the driver type used - the ona that is passed as volume_driver in 
> cinder.conf.
> 
> 
> Thank you in advance for your time.
> 
> 
> Best regards,
> 
> Lukasz
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> 
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Setting up to 3rd party CI OVB jobs

[Emilien Macchi]

On Fri, Oct 7, 2016 at 9:03 AM, Paul Belanger  wrote:
> Greetings,
>
> I wanted to propose a work item, that I am happy to spearhead, about setting 
> up
> a 3rd party CI system for tripleo project. The work I am proposing, wouldn't
> actually affect anything today about tripleo-ci but provider a working example
> of how 3rd party CI will work and potential migration path.
>
> This is just one example of how it would work, obviously everything is open 
> for
> discussions but I think you'll find the plan to be workable. Additionally, 
> this
> topic would only apply to OVB jobs, existing jobs already running on cloud
> providers from openstack-infra would not be affected.
>
> What I am proposing is we move tripleo-test-cloud-rh2 (currently disabled) 
> from
> openstack-infra (nodepool) to rdoproject (nodepool).  This give us a cloud we
> can use for OVB; we know it works because OVB jobs have run on it before.
>
> There is a few issues we'd first need to work on, specifically since
> rdoproject.org is currently using SoftwareFactory[1] we'd need to have them
> adding support for nodepool-builder. This is needed so we can use the existing
> DIB elements that openstack-infra does to create centos-7 images (which 
> tripleo
> uses today). We have 2 options, wait for SF team to add support for this (I
> don't know how long that is, but they know of the request) or we manually 
> setup
> a external nodepool-builder instance for rdoproject.org, which connects to
> nodepool.rdoproject.org via gearman (I suggest we do this).
>
> Once that issue is solved, things are a little easier.  It would just be a
> matter of porting upstream CI configuration to rdoproject.org and validating
> images, JJB jobs and test validation. Cloud credentials removed from
> openstack-infra and added to rdoproject.org.
>
> I'd basically need help from rdoproject (eg: dmsimard) with some of the admin
> tasks, a long with a VM for nodepool-builder. We already have the 3rdparty CI
> bits setup in rdoproject.org, we are actually running DLRN builds on
> python-tripleoclient / python-openstackclient upstream patches.
>
> I think the biggest step is getting nodepool-builder working with Software
> Factory, but once that is done, it should be straightforward work.
>
> Now, if SoftwareFactory is the long term home for this system is open for
> debate.  Obviously, rdoproject has the majority of this infrastructure in 
> plan,
> so it makes for a good place to run tripleo-ci OVB jobs.  Other wise, if there
> are issue, then tripleo would have to stand up their own jenkins/nodepool/zuul
> infrastructure and maintain it.

+1 on this first iteration of building up our own nodepool-builder
instance until Software Factory can provide one.

Thanks for initiating this work,

> I'm happy to answer questions,
> Paul
>
> [1] http://softwarefactory-project.io/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

__
OpenStack Development Mailing 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][Nova] Expose trunk details over metadata API

[Armando M.]

On 7 October 2016 at 06:43, Bence Romsics  wrote:

> Hi,
>
> To follow up on the complications of bringing up trunk subports [1] I
> have written up a small proposal for a tiny new feature affecting
> neutron and nova. That is how to expose trunk details over metadata
> API. To avoid big process overhead I have opened a newton rfe ticket
> [2], plus a nova specless blueprint [3] pointing to it. Please let me
> know if I should have followed a different process.
>
>
Replied on [2]. From a Neutron's standpoint, I suspect you already have
what you need.


> Cheers,
> Bence
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> September/104848.html
> [2] https://bugs.launchpad.net/neutron/+bug/1631371
> [3] https://blueprints.launchpad.net/nova/+spec/trunk-details-meta
>
> __
> OpenStack Development Mailing 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][Nova] Expose trunk details over metadata API

[Jay Pipes]

On 10/07/2016 09:43 AM, Bence Romsics wrote:

Hi,

To follow up on the complications of bringing up trunk subports [1] I
have written up a small proposal for a tiny new feature affecting
neutron and nova. That is how to expose trunk details over metadata
API. To avoid big process overhead I have opened a newton rfe ticket
[2], plus a nova specless blueprint [3] pointing to it. Please let me
know if I should have followed a different process.


Hi Ben,

If I'm reading the Neutron RFE bug correctly, the only change you would 
need in Nova is modifying the column type for the 
instance_metadata.value column from VARCHAR(255) to TEXT.


Is that a correct understanding?

Best,
-jay

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

Re: [openstack-dev] [Neutron][Nova] Expose trunk details over metadata API

[Bence Romsics]

Hi,

Armando: Replied in the RFE comments. Let's continue there.

Jay: Yes, plus the corresponding changes in the API validator.
Practically this: https://review.openstack.org/383801

Cheers,
Bence

On Fri, Oct 7, 2016 at 5:30 PM, Jay Pipes  wrote:
> On 10/07/2016 09:43 AM, Bence Romsics wrote:
>>
>> Hi,
>>
>> To follow up on the complications of bringing up trunk subports [1] I
>> have written up a small proposal for a tiny new feature affecting
>> neutron and nova. That is how to expose trunk details over metadata
>> API. To avoid big process overhead I have opened a newton rfe ticket
>> [2], plus a nova specless blueprint [3] pointing to it. Please let me
>> know if I should have followed a different process.
>
>
> Hi Ben,
>
> If I'm reading the Neutron RFE bug correctly, the only change you would need
> in Nova is modifying the column type for the instance_metadata.value column
> from VARCHAR(255) to TEXT.
>
> Is that a correct understanding?
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tripleo] TripleO RC3

[Emilien Macchi]

Please read Doug's email:
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105266.html

I think it makes sense for us to relax a bit on the RC3 and continue
to work on blockers we wanted fixed in stable/newton.
We already did amazing work to solve most of them, my hope is that we
can release during the next 2 weeks.

AFIK people are still testing upgrades from Mitaka, I"m pretty sure
we'll have more patches to backport.

Actions needed:
- Keep RC3 bugs in https://launchpad.net/tripleo/+milestone/newton-rc3
- they remain our current highest priority to finish.
- Bugs moved from Newton to Ocata-1 stay at this milestone bug can
have newton-backport-potential launchpad tag.
- New bugs are ocata-1 and can have newton-backport-potential if
critical bugfix or upgrade thing.
- Once the bug merged in master, please submit the backport into stable/newton.

People can still continue to use:
https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
To make reviews easier.

Let me know if any question or feedback,

Thanks and happy week-end!

On Thu, Oct 6, 2016 at 9:08 AM, Emilien Macchi  wrote:
> Last reminder before RC3 release that will be proposed on Friday
> morning (eastern time):
>
> - use tripleo/rc3 Gerrit topic
> - please backport rc3 bugfixes merged in master into stable/newton
> - please let me know any blocker
>
> Thanks,
>
> On Fri, Sep 30, 2016 at 10:47 AM, Emilien Macchi  wrote:
>> We have been granted to release a last release candidate (RC3) by next
>> Friday (October 7th).
>>
>> Please use this milestone for the bugs targeted for Newton.
>> https://launchpad.net/tripleo/+milestone/newton-rc3
>>
>> Some reminders:
>> - assign the bug if you're working on it.
>> - update it when you can, we need to know bug status before final RC.
>> - use tripleo/rc3 Gerrit topic to help in reviews:
>> https://review.openstack.org/#/q/topic:tripleo/rc3+status:open
>> - don't forget to backport patches from master to stable/newton branch
>> otherwise they'll not be part of the release.
>>
>> By next Friday, we'll proceed to final RC, any question or feedback is
>> welcome, please let me or shardy know any critical blockers we might
>> have missed.
>>
>> Thanks,
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[openstack-dev] [release][ansible][fuel][kolla][puppet][tripleo] proposed deadlines for cycle-trailing projects

[Doug Hellmann]

This week we tagged the final releases for projects using the
cycle-with-milestones release model. Projects using the cycle-trailing
model have two more weeks before their final release tags are due. In
the time between now and then, we expect those projects to be preparing
and tagging release candidates.

Just as with the milestone-based projects, we want to manage the number,
frequency, and timing of release candidates for cycle-trailing projects.
With that in mind, I would like to propose the following rough timeline
(my apologies for not preparing this sooner):

10 Oct -- All cycle-trailing projects tag at least their first RC.
13 Oct -- Soft deadline for cycle-trailing projects to tag a final RC.
18 Oct -- Hard deadline for cycle-trailing projects to tag a final RC.
20 Oct -- Re-tag the final RCs as a final release.

Between the first and later release candidates, any translations and
bug fixes should be merged.

We want to leave a few days between the last release candidate and
the final release so that downstream consumers of the projects can
report issues against stable artifacts. Given the nature of most
of our trailing projects, and the lateness of starting to discuss
these deadlines, I don't think we need the same amount of time as
we usually set aside for the milestone-based projects. Based on
that assumption, I've proposed a 1 week soft goal and a 2 day hard
deadline.

Let me know what you think,
Doug

Newton schedule: https://releases.openstack.org/newton/schedule.html

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

[openstack-dev] [Fuel][Plugins] Contributing a new fuel-plugin

[Omar Rivera]

Please, could someone help me find the correct process on how to contribute
fuel plugins upstream?

I had followed these instructions but when I opened bug it was declared
invalid - has the process changed perhaps? [1]

I cannot find relevant documentation for how to go about creating the
repository in gerrit and creating the launchpad project correctly. The only
thing I found is the add to the DriverLog repository however they expect
that there is a plugin repository already created.

I had hoped for more instruction in this [2] launchpad project since it
seems to manage bugs for many plugins. Or should it be like the contrail
plugin [3] that has their own page.


​[1]
http://docs.openstack.org/developer/fuel-docs/plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-repo.html
​
​[2] https://launchpad.net/fuel-plugins
[3] https://launchpad.net/fuel-plugin-contrail​

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

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting

[Ed Leafe]

The next meeting of the Nova Scheduler subteam will be on Monday, October 10 at 
1400 UTC in #openstack-meeting-alt
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161010-T14

As always, the agenda is here: 
https://wiki.openstack.org/wiki/Meetings/NovaScheduler

Please add any items you’d like to discuss to the agenda before the meeting.


-- Ed Leafe






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

Re: [openstack-dev] [tripleo] Getting the UI to talk with Undercloud API service endpoints

[Dan Sneddon]

Do you know how awesome it would be if you put this idea into a Blueprint at
http://blueprints.launchpad.net? That would be super-awesome.
File it under tripleo-ui project here if you have a few minutes:

https://blueprints.launchpad.net/specs/+new

- Original Message -
> Hi -
> 
> Great suggestions, Dan.
> 
> To recap, we followed that up with a few other ideas on irc and we eventually
> came to a point to test some of this, with slight modification.
> 
> UI also ships with a configuration file that can override the endpoint
> information received from Keystone. The file is located at
> /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js.
> 
> Part of making this work means enabling SSL on the Undercloud when the UI
> component is selected for installation in undercloud.conf. I think this is
> going to be a pretty reasonable request, but I'm interested in hearing
> feedback from this, and what other implications it may have, that I can't
> think of. The changes I made were all one-off, unmanaged changes, just to
> test this idea out. I'll be doing some more tests but will probably be
> looking for acceptance shortly.
> 
> Once SSL was enabled on the Undercloud, I made two edits to haproxy.cfg that
> were pretty straightforward: added a 'listen' server directive for UI to
> both terminate SSL and forward the request to Apache, and added a 'bind'
> statement for each service that UI expects to talk to (keystone, heat,
> ironic, mistral, swift, zaqar-websocket).
> 
> Once those configuration changes were made, I had a very pleasant experience
> using the UI. It worked exactly as expected. I think this might be a viable
> option.
> 
> Thoughts?
> 
> Thanks!
> -dant
> 
> 
> 
> 
> 
> 
> On Fri, Sep 30, 2016 at 12:21 PM, Dan Sneddon < dsned...@redhat.com > wrote:
> 
> 
> 
> Thinking about this a little more, creating a new unified endpoint on the
> same port as the UI doesn't solve the problem at hand. The UI will use the
> service catalog to find endpoints, so we would need to change the endpoints
> in the service catalog, which changes the flow for the underlying services
> as well.
> 
> Simply moving the control plane services to the external network won't work
> well in environments where the control plane is isolated and non-routed. The
> Undercloud can forward packets, but then becomes a bottleneck and a SPOF.
> 
> A few approaches come to mind, but none of these are quick fixes:
> 
> * Change the UI to get its list of endpoints from somewhere other than the
> service catalog and customize this with URLs that point to the Public VIP.
> Duplicate the services required for the UI on both control plane and
> external network. This might make it possible to make all connections over
> port 443, which is more firewall-friendly (which would be desirable or not
> depending on what kind of firewalling and traffic management is wanted).
> 
> * Relax the rp_filter settings on the Controllers so they accept packets
> destined for the external network on their control plane interfaces; add a
> static route to the Public VIP via the control plane VIP on all
> non-controller nodes. Modify the service catalog to point to the public VIP
> for the services the UI needs. This would need to be combined with a
> security review to determine if additional iptables rules are required.
> 
> * Split the service catalog, so we have an internal and an external view
> depending on where the query came from. I'm not sure how feasible this is.
> 
> Of these, I think the rp_filter settings are the only ones that could be done
> solely with TripleO code changes. That might be worth investigating.
> 
> 
> 
> 
> 
> 
> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com
> 
> On Sep 30, 2016, at 11:36 AM, Dan Sneddon < dsned...@redhat.com > wrote:
> 
> 
> 
> 
> I don't think we can rely on the Undercloud as an API proxy unless we address
> the lack of HA on the Undercloud.
> 
> Wouldn't this be better implemented as as a single, name-based HAProxy
> instance running SSL on port 443 on the overcloud Public VIP? Then we could
> have the same endpoint for Horizon and every other API.
> 
> I actually implemented this scheme in Havana before I joined Red Hat. At the
> time, we had to have a complex HAProxy config and patch the end points to
> support name-based URLs. I think some work has been done in OpenStack now to
> support this model, but I'm not sure where it stands.
> 
> 
> 
> 
> 
> 
> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com
> 
> On Sep 30, 2016, at 9:44 AM, Dan Trainor < dtrai...@redhat.com > wrote:
> 
> 
> 
> 
> Hi -
> 
> I re-read your email a few times and like a few of the things that I see, but
> I'd love some more clarification. As I read it, a few of these things
> conflict. I believe you're suggesting that we don't make these services
> listen on a public interface due to security concerns (and of course,
> enabling SSL would break this because haproxy would listen on these
> 

Re: [openstack-dev] [release][ansible][fuel][kolla][puppet][tripleo] proposed deadlines for cycle-trailing projects

[Emilien Macchi]

On Fri, Oct 7, 2016 at 3:16 PM, Doug Hellmann  wrote:
> This week we tagged the final releases for projects using the
> cycle-with-milestones release model. Projects using the cycle-trailing
> model have two more weeks before their final release tags are due. In
> the time between now and then, we expect those projects to be preparing
> and tagging release candidates.
>
> Just as with the milestone-based projects, we want to manage the number,
> frequency, and timing of release candidates for cycle-trailing projects.
> With that in mind, I would like to propose the following rough timeline
> (my apologies for not preparing this sooner):
>
> 10 Oct -- All cycle-trailing projects tag at least their first RC.
> 13 Oct -- Soft deadline for cycle-trailing projects to tag a final RC.
> 18 Oct -- Hard deadline for cycle-trailing projects to tag a final RC.
> 20 Oct -- Re-tag the final RCs as a final release.

I'm ok with this schedule. We're having some blockers in TripleO,
mostly under control but still not merged in our source code.
I thought we could release RC3 today but it's pointless given the fact
we still have critical bugs open.

This proposal would help us to reduce the list of bugs and make a
better release.

> Between the first and later release candidates, any translations and
> bug fixes should be merged.
>
> We want to leave a few days between the last release candidate and
> the final release so that downstream consumers of the projects can
> report issues against stable artifacts. Given the nature of most
> of our trailing projects, and the lateness of starting to discuss
> these deadlines, I don't think we need the same amount of time as
> we usually set aside for the milestone-based projects. Based on
> that assumption, I've proposed a 1 week soft goal and a 2 day hard
> deadline.
>
> Let me know what you think,
> Doug
>
> Newton schedule: https://releases.openstack.org/newton/schedule.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



-- 
Emilien Macchi

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

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Ken'ichi Ohmichi]

Hi Timur,

2016-10-06 4:08 GMT-07:00 Timur Nurlygayanov :
> Ken, it is a good idea!
>
> The plan is to develop os-faults as a library which will be able
> to manage cluster nodes and OpenStack services on these nodes.
> It is a good idea to add some Tempest tests which will use
> os-faults library as well for some API tests.

Sorry for my misleading, that is not I wanted to say.
I am thinking Tempest doesn't use os-faults as library.
I just wanted to say some destructive tests which will use REST APIs
can be implemented in Tempest instead of os-faults.

For example, the compute service client contains disable_service which
disables nova service but Tempest doesn't contain the corresponding
test cases because Tempest tests need to run in parallel.
https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/services_client.py#L54

If some tests use this method, the other tests which run in parallel
can be failed as unexpected on the gate.
Such tests also are destructive and I am hoping these tests also will
be able to run the gate by finding better way.

> The Stepler framework [1] will use os-faults to perform all destructive
> actions in the clouds (the reboot of nodes, restart of OpenStack services,
> enable/disable network interfaces or some firewall rules and etc).
>
> We need to get +1 from you in [1] to create the repository with
> advanced end-user scenario tests.

OK, I'd like to summarize my thinking here for adding os-faults under
QA project:

Under QA project, the first target of most programs(tempest, devstack,
etc) is for the gate testing.
Of course, some of them are available on production clouds also as the
design, but the first is for the gate.
That means devstack clouds as the first target/purpose.
At this time, this os-faults doesn't seem the gate as the first
purpose based on current implementation.
So I feel os-faults seems different from the existing programs.

os-faults is very young and we will be able to extend it for devstack
clouds also later, I hope.
In addition, I heard this kind of tests(destructive, HA, etc) are
requested from the other users.
So this os-faults seems very valuable for users.

Just in my opinion, I am find to add this os-faults under QA project.
But before that, I'd like to get opinions from the other people of QA team.

Thanks
Ken Ohmichi












> On Tue, Oct 4, 2016 at 8:53 PM, Yaroslav Lobankov 
> wrote:
>>
>> Hi Ken,
>>
>> OS-Faults doesn't have any scenarios in the tree yet (the project is two
>> months old), but you can find some examples of the use in the
>> os-faults/examples directory.
>>
>> Regards,
>> Yaroslav Lobankov.
>>
>> On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
>> wrote:
>>>
>>> Hi Timur,
>>>
>>> Thanks for your explanation.
>>>
>>> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov
>>> :
>>> >
>>> >> I am guessing the above "restart nodes" is for verifying each
>>> >> OpenStack service restarts successfully, right?
>>> >
>>> > Yes, this is right. And we also will check that HA logic for these
>>> > services works correctly (for example, rescheduling of L3 Neutron
>>> > agents for networks).
>>> >
>>> >> But these service scripts are provided by distributors, and Devstack
>>> >> itself doesn't contain service scripts IIUC.
>>> >> So I'd like to know how to verify it on Devstack clouds.
>>> >
>>> > Yes, DevStack doesn't support many scenarios which are actual
>>> > and should be supported on the production clouds.
>>> > It will be not possible to run all advanced test scenarios for DevStack
>>> > clouds,
>>> > just because DevStack can't deploy OpenStack cloud with 3 controllers
>>> > now (so, probably it will be possible in the future).
>>> >
>>> > Of course, some advanced scenarios will support DevStack clouds,
>>> > for example, some test scenarios which are based on customer-found
>>> > issues from the real production clouds, like upload of the large images
>>> > (100+ Gb)
>>> > to Glance with Swift backend. Such cases are important for verification
>>> > of
>>> > pre-production environments, but not very important for CI gate jobs.
>>> >
>>> > It is also important to note that in these advanced cases we are
>>> > targeting
>>> > to check not only the logic of Python code, but also the correct
>>> > configuration
>>> > of all OpenStack components on some pre-production OpenStack clusters.
>>>
>>> I guessed some part of os-faults can be moved to Tempest if os-faults
>>> contains API tests for enabling/disabling OpenStack services.
>>> Then, os-faults would be able to concentrate on more destructive tests
>>> like rebooting physical nodes, etc.
>>> However, I could not find any actual scenarios on current os-faults
>>> (https://github.com/openstack/os-faults).
>>> That seems to just contain some abstraction layers and unit tests. Can
>>> we see actual test scenarios of os-faults ?
>>> Maybe I missed something.
>>>
>>> 

Re: [openstack-dev] [Architecture] APAC friendly meeting time for Architecture Working Group proposed

[joehuang]

Great time slot. Unfortunately not able to attend the first meeting for Oct. 1 
to Oct.7 is public holiday in China.

Best Regards
Chaoyi Huang (joehuang)


From: Clint Byrum [cl...@fewbar.com]
Sent: 05 October 2016 3:04
To: openstack-dev
Subject: [openstack-dev] [Architecture] APAC friendly meeting time for  
Architecture Working Group proposed

Hello, we want to get as much broad participation as possible with the
Architecture Working Group, so I've proposed an alternating odd/even
schedule change here:

https://review.openstack.org/379768

I'm hoping the proposed time is convenient and can be attended by those
in time zones very far ahead of UTC, such as India, China, Japan, Korea,
Australia and New Zealand. The proposed time, 0100 UTC Thursdays, is
a time that I should be able to attend as well, so that I can serve as
chair, though it would be helpful if someone from the timezone stepped
up just in case I'm not able to make it, since this is a bit after my
normal EOD.

So please, if you're not able to attend our current meetings [1], but
you'd like to help with the working group, go +1 or -1 that review to
let us know if that time will help.

Thanks!

[1] https://wiki.openstack.org/wiki/Meetings/Arch-WG

__
OpenStack Development Mailing 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] [murano] IRC Meeting time suggestion

[edison xiang]

Good news!
Thanks very much.

Best Regards,
xiangxinyong

On Mon, Sep 26, 2016 at 11:01 PM, Omar Shykhkerimov <
oshykhkeri...@mirantis.com> wrote:

> Hello team!
>
> As every big project Murano is getting more contributors working on it.
> Our current IRC-meetings are held from 5pm till 6pm UTC every Tuesday, but
> it looks like this time isn't comfortable for every Murano contributor.
>
> Here is the suggestion: have alternating meetings: at 5PM UTC on Tuesday
> on the first week and at 12AM UTC (7 hours earlier) on Tuesday on the
> second week. I hope it will allow more people to visit the meetings.
>
> So the suggested schedule is:
>
> 27 of September: from 5pm to 6pm UTC at #openstack-meeting-alt (as usual)
>
> 4 of October: from 12am to 1pm UTC at #openstack-meeting-alt
>
> 11 of October: from 5pm to 6pm UTC at #openstack-meeting-alt
>
> 18 of October: from 12am to 1pm UTC at #openstack-meeting-alt
>
> ...
>
> and so on.
>
> Looking forward to your opinions - whether this timetable is more
> comfortable.
> Please tell us in this thread if you have objections on suggested schedule.
>
>
> Thanks,
>
> Omar Shykhkerimov
>
> __
> OpenStack Development Mailing 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] [all][tc] Cross Project workshops in Barcelona including "Re-inventing the TC"

[Davanum Srinivas]

Folks,

Please see the cross project schedule over at:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Cross%20Project%20workshops%3A

For those of you who are very interested in how TC works and what it
can/should do. Please mark on your calendar:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16923/cross-project-workshops-re-inventing-the-tc-the-stewardship-working-group-discussion

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] [Congress] PTG planning

[Masahito MUROI]

Thanks summarizing it, Eric.

Combination of 1. and 2. looks good.

Basically, we'll have work sessions in PTG for next release. Other teams 
and operator could come, so it's easy for Congress team to discuss 
anything with them.


Then if needed, we can have unofficial work session of Congress team at 
summit instead of mid-cycle. We don't need to consider hosts and 
location. Additionally, we could meet Congress user who has a 
presentation and nice usecase but doesn't contribute actively.


best regards,
Masahito

On 2016/10/06 16:53, Thierry Carrez wrote:

Good summary. It is true that for small-to-medium sized teams (which did
not routinely organize midcycles), there is a tough choice to make.

See a couple of remarks inline:

Eric K wrote:

Here are some of our choices as a team, as well as some first thoughts on
pros and cons:

1. Do work sessions at PTGs; no organized work sessions at summits.
Pro: schedule lines up wit beginning of dev cycle
Pro: work room available
Pro: easy to collaborate with other teams
Con: extra travel for those who will continue to attend summit.


+Pro: PTGs are organized in cheaper locations and closer to the center
of mass of contributors, hopefully making it less costly to travel to
overall
+Pro: More team time (for Congress: 2-3 days instead 2-3 hours) for a
better return on travel investment


2. Unofficial work session at summits; no work sessions at PTGs.
Pro: For people who would be going to the summits anyway, this option
reduces travel.
Con: probably no official work room available.
Con: happens at the middle of a dev cycle

3. Separately organize work sessions in the style of past mid-cycle
sprints; no work sessions at any of the official openstack events.
Pro: we can choose schedule and location
Con: harder to collaborate with other teams


+Con: extra travel for those who will continue to attend summit




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



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

[openstack-dev] [cinder] How to retrieve volume_driver

[crow1]

Dear all.

I'm a PHD student from Poland and have found out about this list from Openstack 
wiki. Could you kindly tell me, if there is a way to retrieve, from outside of 
OpenStack code, volume_driver for given backend? Preferably - without a need to 
parse the cinder.conf file?

It is fairly easy to retrieve the volume_backend_name, which in most scenarios 
seems to describe the driver type used. However, in general scenario, this is 
just a custom string entered by the admin. I would greatly appreciate, if 
someone could point me to a way to acquire the unique stirng, identifying the 
driver type used - the ona that is passed as volume_driver in cinder.conf.

Thank you in advance for your time.

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

Re: [openstack-dev] [mistral] Who's interested in attending PTG?

[Renat Akhmerov]

Yes, thanks for clarification Clint.

Renat Akhmerov
@Nokia

> On 6 Oct 2016, at 20:02, Clint Byrum  wrote:
> 
> Excerpts from Renat Akhmerov's message of 2016-10-06 19:21:40 +0700:
>> Hi,
>> 
>> As you likely know, the summit format will change after Barcelona. There 
>> will be two events now: PTG (Project Team Gathering) for design sessions and 
>> OpenStack Summit which is more customer/promotion oriented . The first will 
>> take place in Atlanta on Feb 20-24, 2017 and the second one in May 2017 in 
>> Boston. More about that at [1]. Please read it.
> 
> May 2017 is the OpenStack Conference, not a PTG. Teams are welcome to
> schedule a mid-cycle coinciding with this event to take advantage of
> contributors attending the conference, but it's not an "everyone together
> in one place" event.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [kolla] ~root and /etc of osic testing

[Steven Dake (stdake)]

Hey folks,

Several people have asked for archives of the OSIC work we did.  Those files 
can be found here:

https://drive.google.com/drive/folders/0B8q6xDPETSkHc05fR21qeElpc2M?usp=sharing

Regards,
-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] [heat] Presence at PTG, Atlanta

[Sergey Kraynev]

Rabi, thank you for the information.

I think, that we need to attend as a team. So I agree with you opinion
about option 1.
Also I have a question: When do we need prepare new list of topics for
design sessions for this event ?

On 7 October 2016 at 08:48, Rabi Mishra  wrote:

> Hi All,
>
> As you would probably know, the first Project Teams Gathering(PTG) will
> happen in Atlanta from Feb 20-24, 2017.
>
> Organizers are working on the event space layout and have asked all
> project teams on their plans to join the event and whether they would
> require/use a separate room.
>
> As this is expected to be a substitute for the 'design summit' plus
> 'mid-cycle meet up' (I'm not sure if we had one before), I assume most the
> contributors would be planning to attend it.
>
>
> We can respond with one of the options below on 'Whether the project team
> is planning to gather for the event?'
>
> 1. Yes, Absolutely
> 2. Maybe, Still Considering it
> 3. No Certainly Not
>
> I think for us it's '1'. However, please let us know if you have different
> idea/opinion on this. We can also discuss about it in the team meeting this
> week.
>
>
> --
> Regards,
> Rabi Misra
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Sergey.
__
OpenStack Development Mailing 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] FYI, nova plans to have a room at the PTG in February

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Matt Riedemann's message of 2016-10-06 13:52:09 -0500:
>> Sorry yeah I screwed that up. I re-read the PTG email and the first two 
>> days are cross-project things, and Wed-Fri are meetup style at the PTG, 
>> it's not time-boxed sessions like the design summit, unless again I'm 
>> screwing this up and this is just a thing that's not explainable to mere 
>> mortals until we actually experience one.
> 
> It's not fully time-boxed, but as Clint pointed out it might be
> useful to establish some sort of estimated schedule so cross-team
> discussions can be coordinated.

The first two days are for horizontal teams and cross-project effort
participants to meet. Those are *not* 40-min timeboxed fishbowl
discussions, each room will be dedicated to a given effort for two full
days.

That said, to facilitate having critical discussions, we'll set up some
system to announce that a specific discussion will happen at a specific
time. Open to options here (could be low-tech like mailing-list or
whiteboard, high-tech with some specific webapp), but the idea would be
to be able to easily find out when you should probably go out of your
team room and join another.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [keystone] design session schedule and etherpads

[Steve Martinelli]

Hey Keystoners,

I've created an initial draft of the keystone design session schedule. A
live view is at [1]. I'm attaching the times, etherpads, and descriptions
for each fishbowl / work session. So please start priming the etherpads
with content. Also bookmark them!

You'll notice we have one fishbowl session left, I'm taking suggestions for
what we should discuss during that time. I would prefer it to be something
that everyone can participate in, rather than a very targeted design
discussion that is better left for a work session.


Wed 26, 4:05pm-4:45pm
Keystone: Newton retrospective (Fishbowl)
https://etherpad.openstack.org/p/keystone-newton-retrospective

Wed 26, 4:55pm-5:35pm
Keystone: TBD (Fishbowl)

Thu 27, 12:00pm-12:40pm
Keystone: Unconference (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-unconference

Thu 27, 12:50pm-1:30pm
Keystone: Ocata priorities (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-priorities

Thu 27, 2:50pm-3:30pm
Keystone: Work session (Federation)
https://etherpad.openstack.org/p/ocata-keystone-federation

Thu 27, 3:40pm-4:20pm
Keystone: Work session (Testing)
https://etherpad.openstack.org/p/ocata-keystone-testing

Thu 27, 4:30pm-5:10pm
Keystone: Work session (Documentation)
https://etherpad.openstack.org/p/ocata-keystone-documentation

Fri 28, 10:00am-10:40am
Keystone: Work session (Authorization)
https://etherpad.openstack.org/p/ocata-keystone-authorization

Fri 28, 10:50am-11:30am
Keystone: Work session (Authentication)
https://etherpad.openstack.org/p/ocata-keystone-authentication

Fri 28, 12:00pm-12:40pm
Keystone: Work session (Scaling and Performance)
https://etherpad.openstack.org/p/ocata-keystone-scaling

Fri 28, 12:50pm-1:30pm
Keystone: Work session (Integration)
https://etherpad.openstack.org/p/ocata-keystone-integration

Fri 28, 3:00pm-7:00pm
Keystone: Contributors meetup
(No etherpad)


[1]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Keystone%3A
__
OpenStack Development Mailing 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][API WG] How does one best express a time interval as an API filtering query?

[milanisko k]

Guys,

thanks for the suggestions! I like the coma separation as well, it's the
closest to the ISO style.
Let me propose the update.

Cheers,
milan

čt 6. 10. 2016 v 19:28 odesílatel Jay Pipes  napsal:

> On 10/06/2016 11:43 AM, Jeremy Stanley wrote:
> > On 2016-10-06 10:30:30 -0500 (-0500), Kevin L. Mitchell wrote:
> > [...]
> >> Problem with that is that ':' is a valid character within an ISO date,
> >> though I do like the 'between' prefix.  Now, '/' can be used if it's URL
> >> encoded, but I agree that that is non-ideal.  How about a syntax
> >> something like:
> >>
> >> ?finished_at=between:ISO_DATE_A@ISO_DATE_B
> _at=between:ISO_DATE_C@ISO_DATE_D
> >
> > I'll admit I'm not up on the intricacies of URL expectations for
> > APIs, but why not just use a comma? That's not an unusual meaning
> > for it as punctuation (at least in English), and has the property
> > that it's not overloading a typical field separator within either
> > 8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
> > the month.)
>
> Yup, ++ on a comma.
>
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Presence at PTG, Atlanta

[Thierry Carrez]

Sergey Kraynev wrote:
> Rabi, thank you for the information.
> 
> I think, that we need to attend as a team. So I agree with you opinion
> about option 1.
> Also I have a question: When do we need prepare new list of topics for
> design sessions for this event ? 

Note that the PTG will not be organized into arbitrary 40-min time
slots. Teams will be given a room and a number of days (2 or 3), and
then you are free to organize your time as you see fit (more like what
happens on the "contributors meetup" on Fridays at the Design Summit,
and at midcycle sprints).

So while you may still want to prepare a list of topics for your team
gathering at the PTG, it doesn't have to be artificially lined up with a
number of 40-min time slots, and you can decide the contents at the last
minute.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

[Thierry Carrez]

Clint Byrum wrote:
> Excerpts from Matt Riedemann's message of 2016-10-06 11:33:35 -0500:
>> Remember at a high level that the PTG is the replacement for the 
>> midcycle meetups, except it's centrally located and organized by the 
>> foundation, and it's at the release boundaries rather than the middle.
>>
>> The traditional summit that we're used to is now in the middle of the 
>> release and is more for the marketing stuff that happens at the summit 
>> whereas the PTG is supposed to be strictly technical and for 
>> development, like the design summit.
> 
> That's a bit different than the way I understood it. My understanding
> was that it was more like the fishbowls still happen, at the PTG, and the
> work rooms at the end of the week at the PTG would replace the mid-cycles.
> 
> If we don't have fishbowls anymore, we are going to end up siloing even
> harder than we already do.

As mentioned elsewhere in this thread, cross-project efforts will have
time and space in the first part of the PTG week, while vertical teams
will have time and space in the second part of the PTG week. By
separating the time frames dedicated to vertical teams and cross-project
teams, we actually hope to encourage people to break out their natural silo.

It's also worth noting that there will still be cross-community
discussions (think: some Ops with some Devs with some End users in
fishbowls to discuss community-wide topics) at the "Forum" part at the
OpenStack Summit starting in Boston. We don't need *all* developers to
be present, but enough devs (and enough ops and enough end users) should
be present to allow us to successfully close the feedback loop (a bit
similar to what we did with encouraging PTLs and other devs to attend
Ops Summit / Ops midcycles).

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [heat] Presence at PTG, Atlanta

[Sergey Kraynev]

Thierry,

Thank you for the clarification :)

On 7 October 2016 at 11:35, Thierry Carrez  wrote:

> Sergey Kraynev wrote:
> > Rabi, thank you for the information.
> >
> > I think, that we need to attend as a team. So I agree with you opinion
> > about option 1.
> > Also I have a question: When do we need prepare new list of topics for
> > design sessions for this event ?
>
> Note that the PTG will not be organized into arbitrary 40-min time
> slots. Teams will be given a room and a number of days (2 or 3), and
> then you are free to organize your time as you see fit (more like what
> happens on the "contributors meetup" on Fridays at the Design Summit,
> and at midcycle sprints).
>
> So while you may still want to prepare a list of topics for your team
> gathering at the PTG, it doesn't have to be artificially lined up with a
> number of 40-min time slots, and you can decide the contents at the last
> minute.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Sergey.
__
OpenStack Development Mailing 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] proper cleanup of l3 resources (neutron-netns-cleanup)

[Sergey Belous]

Hello everyone.

I’m very interesting in this one 
https://bugs.launchpad.net/neutron/+bug/1403455 
Can anybody tell me, what is the current status of this bug? Is anybody working 
on it now?
And as I can see, there are some options, that was discussed in comments to 
this bug and… did anybody decide which solution is the best?


--
Best Regards,
Sergey Belous

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

Re: [openstack-dev] [cinder] How to retrieve volume_driver

[Erlon Cruz]

Hi Luzasz,

This information (volume_driver) is only used on driver loading so, its not
available outside Cinder context. Can you tell how and why you need that?
And why parsing the conf file is not enough for you?

Erlon

On Fri, Oct 7, 2016 at 9:05 AM,  wrote:

> Dear all.
>
> I'm a PHD student from Poland and have found out about this list from
> Openstack wiki. Could you kindly tell me, if there is a way to retrieve,
> from outside of OpenStack code, volume_driver for given backend? Preferably
> - without a need to parse the cinder.conf file?
>
> It is fairly easy to retrieve the volume_backend_name, which in most
> scenarios seems to describe the driver type used. However, in general
> scenario, this is just a custom string entered by the admin. I would
> greatly appreciate, if someone could point me to a way to acquire the
> unique stirng, identifying the driver type used - the ona that is passed as
> volume_driver in cinder.conf.
>
> Thank you in advance for your time.
>
> Best regards,
> Lukasz
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Setting up to 3rd party CI OVB jobs

[Paul Belanger]

Greetings,

I wanted to propose a work item, that I am happy to spearhead, about setting up
a 3rd party CI system for tripleo project. The work I am proposing, wouldn't
actually affect anything today about tripleo-ci but provider a working example
of how 3rd party CI will work and potential migration path.

This is just one example of how it would work, obviously everything is open for
discussions but I think you'll find the plan to be workable. Additionally, this
topic would only apply to OVB jobs, existing jobs already running on cloud
providers from openstack-infra would not be affected.

What I am proposing is we move tripleo-test-cloud-rh2 (currently disabled) from
openstack-infra (nodepool) to rdoproject (nodepool).  This give us a cloud we
can use for OVB; we know it works because OVB jobs have run on it before.

There is a few issues we'd first need to work on, specifically since
rdoproject.org is currently using SoftwareFactory[1] we'd need to have them
adding support for nodepool-builder. This is needed so we can use the existing
DIB elements that openstack-infra does to create centos-7 images (which tripleo
uses today). We have 2 options, wait for SF team to add support for this (I
don't know how long that is, but they know of the request) or we manually setup
a external nodepool-builder instance for rdoproject.org, which connects to
nodepool.rdoproject.org via gearman (I suggest we do this).

Once that issue is solved, things are a little easier.  It would just be a
matter of porting upstream CI configuration to rdoproject.org and validating
images, JJB jobs and test validation. Cloud credentials removed from
openstack-infra and added to rdoproject.org.

I'd basically need help from rdoproject (eg: dmsimard) with some of the admin
tasks, a long with a VM for nodepool-builder. We already have the 3rdparty CI
bits setup in rdoproject.org, we are actually running DLRN builds on
python-tripleoclient / python-openstackclient upstream patches.

I think the biggest step is getting nodepool-builder working with Software
Factory, but once that is done, it should be straightforward work.

Now, if SoftwareFactory is the long term home for this system is open for
debate.  Obviously, rdoproject has the majority of this infrastructure in plan,
so it makes for a good place to run tripleo-ci OVB jobs.  Other wise, if there
are issue, then tripleo would have to stand up their own jenkins/nodepool/zuul
infrastructure and maintain it. 

I'm happy to answer questions,
Paul

[1] http://softwarefactory-project.io/

__
OpenStack Development Mailing 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] proper cleanup of l3 resources (neutron-netns-cleanup)

[Miguel Angel Ajo Pelayo]

Hi Sergey!,

This was my point of view on a possible solution:

https://bugs.launchpad.net/neutron/+bug/1403455/comments/12

"""
After much thinking (and quite little doing) I believe the option "2"
I proposed is a rather reasonable one:

2) Before cleaning a namespace blindly in the end, identify any
network service in the namespace (via netstat), kill those processes,
so they aren't orphaned, and then, kill the namespace.

Any process should be safely killed that way, and if it's not, we can
complicate our lifes and code with "1":
1) Use stevedore HookManager to let out-of-tree repos register netns
prefixes declaration, and netns cleaners,
so every piece of code (in-tree or out-of-tree) declare which
netns prefixes they use, and provide a netns cleanup
hook to be called.

"""

Let me know what you think

On Fri, Oct 7, 2016 at 2:15 PM, Sergey Belous  wrote:
> Hello everyone.
>
> I’m very interesting in this one
> https://bugs.launchpad.net/neutron/+bug/1403455
> Can anybody tell me, what is the current status of this bug? Is anybody
> working on it now?
> And as I can see, there are some options, that was discussed in comments to
> this bug and… did anybody decide which solution is the best?
>
>
> --
> Best Regards,
> Sergey Belous
>
>
> __
> OpenStack Development Mailing 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] Affinity instance slot reservation

[Daniel Pawlik]

Nova scheduler don't reserve any slots for new instances with affinity 
policy.


I've created a bug on Launchpad 
(https://bugs.launchpad.net/nova/+bug/1630929) which describes the 
problem and my solution.


Please let me know what you think about it.


Regards


__
OpenStack Development Mailing 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] Stadium evolution - final stage

[Armando M.]

Neutrinos,

As some of you may have noticed, there has been a fresh batch of patches on
topic [1]. After having worked on [2][3] during the span of Newton, we are
approaching now the final stage of this consolidation effort, where I
attempt to define a procedure for transparently letting the Neutron
community assess how a subproject meets the standard of quality that any
Neutron-led effort should have.

I started with fwaas and vpnaas so far, and I'll reach out individually to
the maintainers of projects [4] to accurately capture the rest of the
picture. LBaas/Octavia will not be assessed as it's already been agreed
their spinoff [5]. Please bear in mind that the deadline for completing
this assessment effort is firmly set to be Ocata-1 (Nov 14 2016).

Many thanks,
Armando

[1] https://review.openstack.org/#/q/topic:stadium-implosion+status:open
[2] http://specs.openstack.org/openstack/neutron-specs/
specs/newton/neutron-stadium.html
[3] http://docs.openstack.org/developer/neutron/stadium/index.html
[4] http://governance.openstack.org/reference/projects/neutron.html
[5] https://specs.openstack.org/openstack/neutron-specs/
specs/newton/kill-neutron-lbaas.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Getting DetachedInstanceError from sqlalchemy on instance.get_by_uuid()

[Beliveau, Ludovic]

Hi all,

In kilo (yeah I know it's an old release, but still :)), I was getting a nova 
errors for DetachedInstanceError on instance.get_by_uuid().

2016-10-05 18:30:53.791 103618 ERROR nova.api.metadata.handler 
[req-5aa7b422-d6c0-424e-b40f-cea79d3a3963 - - - - -] Failed to get metadata for 
instance id: 859aba9c-7620-4cbf-a5aa-f6f29c320980
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler Traceback (most 
recent call last):
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/api/metadata/handler.py", line 220, in 
_handle_instance_id_request
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
remote_address)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/api/metadata/handler.py", line 106, in 
get_metadata_by_instance_id
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler instance_id, 
address)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/api/metadata/base.py", line 531, in 
get_metadata_by_instance_id
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler instance = 
objects.Instance.get_by_uuid(ctxt, instance_id)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/base.py", line 163, in wrapper
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler result = 
fn(cls, context, *args, **kwargs)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/instance.py", line 654, in 
get_by_uuid
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
expected_attrs)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/instance.py", line 608, in 
_from_db_object
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
instance._maybe_migrate_flavor(db_inst, expected_attrs)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/instance.py", line 535, in 
_maybe_migrate_flavor
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler if 
instance_extra.get('flavor') is not None:
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/oslo_db/sqlalchemy/models.py", line 60, in 
get
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler return 
getattr(self, key, default)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/attributes.py", line 239, in 
__get__
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler return 
self.impl.get(instance_state(instance), dict_)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/attributes.py", line 591, in 
get
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler value = 
self.callable_(state, passive)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/strategies.py", line 279, in 
_load_for_state
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
(orm_util.state_str(state), self.key)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
DetachedInstanceError: Parent instance  is not 
bound to a Session; deferred load operation of attribute 'flavor' cannot proceed

Now I've fixed it by adding a "joinedload" in the database query (in 
instance_get_by_uuid()) on 'extra'.

So this fixes the issue, what I'd like to understand is why in most cases (like 
99.9% of the time), the code was still working without the "joinedload" ?  What 
could explain that the children object was loaded but at some point dropped 
from the session ?

I tried to reproduce the issue in mitaka (sorry didn't had a newton setup), but 
it appears I can't reproduce it there ...  I was hoping to reproduce it and 
make sure there is no latent bug in nova.

Has anybody seen this issue before or something similar ?

Thanks for the help,
/ludovic
__
OpenStack Development Mailing 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] [murano] IRC Meeting time suggestion

[caowei]

 +1


 [openstack-dev] [murano] IRC Meeting time suggestion

*Omar Shykhkerimov* oshykhkerimov at mirantis.com 


/Mon Sep 26 15:01:48 UTC 2016/

 * Previous message: [openstack-dev] [puppet] [infra] Request for old
   branches removal
   

 * Next message: [openstack-dev] [murano] IRC Meeting time suggestion
   

 * *Messages sorted by:* [ date ]
   

   [ thread ]
   

   [ subject ]
   

   [ author ]
   





Hello team!

As every big project Murano is getting more contributors working on it. Our
current IRC-meetings are held from 5pm till 6pm UTC every Tuesday, but it
looks like this time isn't comfortable for every Murano contributor.

Here is the suggestion: have alternating meetings: at 5PM UTC on Tuesday on
the first week and at 12AM UTC (7 hours earlier) on Tuesday on the second
week. I hope it will allow more people to visit the meetings.

So the suggested schedule is:

27 of September: from 5pm to 6pm UTC at #openstack-meeting-alt (as usual)

4 of October: from 12am to 1pm UTC at #openstack-meeting-alt

11 of October: from 5pm to 6pm UTC at #openstack-meeting-alt

18 of October: from 12am to 1pm UTC at #openstack-meeting-alt

...

and so on.

Looking forward to your opinions - whether this timetable is more
comfortable.
Please tell us in this thread if you have objections on suggested schedule.


Thanks,

Omar Shykhkerimov

__
OpenStack Development Mailing 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] [telemetry] Deprecating the Ceilometer API

[Lu, Lianhao]

I know customers are using the 'pushing sample API', but don’t know whether 
they're applying transformer to those data or not.

-Lianhao Lu

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Wednesday, October 05, 2016 12:35 AM
> To: gordon chung
> Cc: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [telemetry] Deprecating the Ceilometer
> API
> 
> On Tue, Oct 04 2016, gordon chung wrote:
> 
> > so one thing we probably do need to keep is the ability push samples
> > (and events?). i know previously people were actually using this
> feature.
> 
> That's debatable.
> 
> Pushing events is IMHO out of scope of Ceilometer – it's related to
> oslo.messaging notification at this point. So if we want to allow that via
> an API endpoint, we should build one in OpenStack over
> oslo.messaging. Good idea or not, I don't know.
> 
> Pushing samples is probably doable with some kind of small API, but I
> am not sure it's worth anything. You could still directly push the data to
> Gnocchi and save some you some load. Unless you have transformers
> to apply, but… really?
> 
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Schedule Instances according to Local disk based Volume?

[Zhenyu Zheng]

So do we like the idea of "volume based scheduling?"

On Tue, Sep 27, 2016 at 11:39 AM, Joshua Harlow 
wrote:

> Huang Zhiteng wrote:
>
>>
>>
>> On Tue, Sep 27, 2016 at 12:00 AM, Joshua Harlow > > wrote:
>>
>> Huang Zhiteng wrote:
>>
>>
>> On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow
>> 
>> >>
>>
>> wrote:
>>
>>  Huang Zhiteng wrote:
>>
>>  In eBay, we did some inhouse change to Nova so that our
>> big data
>>  type of
>>  use case can have physical disks as ephemeral disk for
>> this type of
>>  flavors.  It works well so far.   My 2 cents.
>>
>>
>>  Is there a published patch (or patchset) anywhere that
>> people can
>>  look at for said in-house changes?
>>
>>
>> Unfortunately no, but I think we can publish it if there are
>> enough
>> interests.  However, I don't think that can be easily adopted onto
>> upstream Nova since it depends on other in-house changes we've
>> done to Nova.
>>
>>
>> Is there any blog, or other that explains the full bunch of changes
>> that ebay has done (u got me curious)?
>>
>> The nice thing about OSS is that if u just get the patchsets out
>> (even to github or somewhere), those patches may trigger things to
>> change to match your usecase better just by the nature of people
>> being able to read them; but if they are never put out there, then
>> well ya, it's a little hard to get anything to change.
>>
>>
>> Anything stopping a full release of all in-house changes?
>>
>> Even if they are not 'super great quality' it really doesn't matter :)
>>
>> Apology for sidetracking the topic a bit.  While we encourage our
>> engineers to embrace community and open source, I think we didn't do a
>> good job to actually emphasize that. 'Time To Market' is another factor,
>> usually a feature requirement becomes deployed service in 2,3 sprint
>> (4~6 weeks), but you know how much can be done in same amount of time in
>> community, especially with Nova. :)
>>
>
> Ya, sorry for side-tracking,
>
> Overall yes I do know getting changes done in upstream is not a 4-6 week
> process (though maybe someday it could be). In general I don't want to turn
> this into a rant, and thankfully I think there is a decent LWN article
> about this kind of situation already. You might like it :)
>
> https://lwn.net/Articles/647524/ (replace embedded linux/kernel in this
> with openstack and imho it's equally useful/relevant).
>
>
> -Josh
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [Trove] trove core team

[Craig Vyvial]

Whats up yall.

So I've changed my focus over the last couple months to working on some new
technology and do not have time to fulfill my duties as Trove Core any
longer. I think its time to move on and step down from trove core.

I have been around for a while and seen the Trove community grow and seen
great strides of development within Trove. I look forward to seeing the
future of what Trove will offer within the OpenStack ecosystem. I've truly
enjoyed my time hanging out, working with, and getting to know everyone.
Feel free to contact me if you have wanna chat or just hang out if you
around around the Austin area.

Thanks,
Craig Vyvial
__
OpenStack Development Mailing 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] [murano] IRC Meeting time suggestion

[刘楠科]

The time is better than before for me and i will attend the meeting.




thanks，
Nanke




__
OpenStack Development Mailing 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] Ocata Design Summit: Couple of empty slots up for grabs

[Thierry Carrez]

Zhipeng Huang wrote:
> Nomad team would also like to see if one of the slots would be available
> :) either one would work fine for us

3 requests for 2 slots... We gave preference to existing teams (or teams
already proposed for becoming an official project, so Fuel got the
additional fishbowl and Storlets got the additional workroom.

We also swapped the Fuel and Storlets fishbowls so that Storlets can
have a their fishbowl without conflicting with a Swift session.

I'll let you know if some other slot frees up !

-- 
Thierry Carrez (ttx)

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