Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-26 Thread Joshua Hesketh
On Sat, Jun 25, 2016 at 10:44 AM, Robert Collins wrote: > Removing the pbr branch should be fine - it was an exceptional thing > to have that branch in the first place - pbr is consumed by releases > only, and due to its place in the dependency graph is very very very

Re: [openstack-dev] [constraints] Updating stable branch URL

2016-06-26 Thread Tony Breeds
On Mon, Jun 27, 2016 at 03:08:18PM +1000, Sachi King wrote: > To facilitate upper-constraints on developer systems we have a > hard-coded URL in projects tox.ini. This URL needs to change when > after the openstack/requirements repo has created a branch for the > stable release. > > This is in

[openstack-dev] [constraints] Updating stable branch URL

2016-06-26 Thread Sachi King
To facilitate upper-constraints on developer systems we have a hard-coded URL in projects tox.ini. This URL needs to change when after the openstack/requirements repo has created a branch for the stable release. This is in reference to [0]. There was some mention of possibly adding this to

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-26 Thread Joshua Hesketh
On Sat, Jun 25, 2016 at 4:20 AM, Sumit Naiksatam wrote: > Hi, I had earlier requested in this thread that the stable/kilo branch > for the following repos be not deleted: > > > openstack/group-based-policy > > openstack/group-based-policy-automation > >

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-26 Thread Joshua Hesketh
On Sat, Jun 25, 2016 at 4:20 AM, Sumit Naiksatam wrote: > Hi, I had earlier requested in this thread that the stable/kilo branch > for the following repos be not deleted: > > > openstack/group-based-policy > > openstack/group-based-policy-automation > >

[openstack-dev] [tricircle] Overlay L2 networking across OpenStack slides used in OPNFV summit

2016-06-26 Thread joehuang
Hello, In last week OPNFV summit in Berlin, a presentation was given about "Overlay L2 networking across OpenStack", the slides is for your reference: https://docs.google.com/presentation/d/1Cv23dLAmSB57IpD-nt-TH5lrCehcoeiml7HpvgUWauo/edit#slide=id.g1478638225_0_0 Best Regards Chaoyi Huang (

Re: [openstack-dev] [grenade] upgrades vs rootwrap

2016-06-26 Thread Angus Lees
On Mon, 27 Jun 2016 at 12:59 Tony Breeds wrote: > On Mon, Jun 27, 2016 at 02:02:35AM +, Angus Lees wrote: > > > *** > > What are we trying to impose on ourselves for upgrades for the present > and > > near future (ie: while rootwrap is still a thing)? > > *** > > > >

Re: [openstack-dev] [grenade] upgrades vs rootwrap

2016-06-26 Thread Tony Breeds
On Mon, Jun 27, 2016 at 02:02:35AM +, Angus Lees wrote: > *** > What are we trying to impose on ourselves for upgrades for the present and > near future (ie: while rootwrap is still a thing)? > *** > > A. Sean says above that we do "offline" upgrades, by which I _think_ he > means a

Re: [openstack-dev] [grenade] upgrades vs rootwrap

2016-06-26 Thread Angus Lees
On Fri, 24 Jun 2016 at 19:13 Thierry Carrez wrote: > In summary, I think the choice is between (1)+(4) and doing (4) > directly. How doable is (4) in the timeframe we have ? Do we all agree > that (4) is the endgame ? > I don't make predictions about development timelines

Re: [openstack-dev] [grenade] upgrades vs rootwrap

2016-06-26 Thread Angus Lees
On Fri, 24 Jun 2016 at 20:48 Sean Dague wrote: > On 06/24/2016 05:12 AM, Thierry Carrez wrote: > > I'm adding Possibility (0): change Grenade so that rootwrap filters from > > N+1 are put in place before you upgrade. > > If you do that as general course what you are saying is

Re: [openstack-dev] [tripleo] CI down - No connected Gearman servers

2016-06-26 Thread Emilien Macchi
Dan restarted Gearman, but CI is still failing on something else now: qemu-img convert -f raw -O qcow2 /opt/stack/new/overcloud-full.raw /opt/stack/new/overcloud-full.qcow2 qemu-img: error while writing sector 8217856: No space left on device I still don't have access to anything but I hope it

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

2016-06-26 Thread Robert Collins
On 27 June 2016 at 13:20, Jens Rosenboom wrote: > 2016-06-22 9:18 GMT+02:00 Victor Stinner : >> Hi, >> >> Current status: only 3 projects are not ported yet to Python 3: >> >> * nova (76% done) >> * trove (42%) >> * swift (0%) >> >>

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

2016-06-26 Thread Jens Rosenboom
2016-06-22 9:18 GMT+02:00 Victor Stinner : > Hi, > > Current status: only 3 projects are not ported yet to Python 3: > > * nova (76% done) > * trove (42%) > * swift (0%) > >https://wiki.openstack.org/wiki/Python3 How should differences between python3.4 and python3.5 be

Re: [openstack-dev] [mistal] Mistral logo ideas?

2016-06-26 Thread hie...@vn.fujitsu.com
Hi folks, Maybe smth simple like that: http://prntscr.com/blhcyq De : Ilya Kutukov [ikutu...@mirantis.com] Envoyé : vendredi 24 juin 2016 13:25 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [mistal] Mistral

Re: [openstack-dev] [Heat][tripleo] Tripleo holding on to old, bad data

2016-06-26 Thread Steve Baker
Assuming the stack is deleted and nova is showing no servers, you likely have ironic nodes which are not in a state which can be scheduled. Do an ironic node-list, you want Power State: Off, Provisioning State: available, Maintenance: False On 25/06/16 09:27, Adam Young wrote: A coworker

Re: [openstack-dev] [Fuel] Merge IRC channels

2016-06-26 Thread Kirill Zaitsev
Just wanting to share an opinion: We in murano had similar discussion about a year ago, and ultimately decided that it’s not worth the work to rename #murano into #openstack-murano, support the deprectated channel, edit documents, and move people around. After all there is #heat #tacker and

[openstack-dev] [all][Python 3.4-3.5] Async python clients

2016-06-26 Thread Denis Makogon
Hello stackers. I know that some work in progress to bring Python 3.4 compatibility to backend services and it is kinda hard question to answer, but i'd like to know if there are any plans to support asynchronous HTTP API client in the nearest future using aiohttp [1] (PEP-3156)? If yes, could