Re: [openstack-dev] [oslo] zeromq work for kilo

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/09/14 15:34, Doug Hellmann wrote:
> This thread [1] has turned more “future focused", so I’m moving the
> conversation to the -dev list where we usually have those sorts of
> discussions.
[...]
>> I'd also like to document the current design of the ZMQ driver -
>> Doug - where is the best place todo this? I thought in the source
>> tree somewhere.
> 
> The documentation in the oslo.messaging repository [2] would be a
> good place to start for that. If we decide deployers/operators need
> the information we can either refer to it from the guides managed
> by the documentation team or we can move/copy the information. How
> about if you start a new drivers subdirectory there, and add
> information about zmq. We can have other driver authors provide
> similar detail about their drivers in the same directory.
> 
> [2]
> http://git.openstack.org/cgit/openstack/oslo.messaging/tree/doc/source

OK
> 
- - I'll raise a review with some appropriate design documentation
sometime in the next few weeks.

>> 2) a list of the critical bugs that need to be fixed + any
>> existing patches associated with those bugs, so they can be
>> reviewed early in kilo
[...]
> That’s a good list, and shorter than I expected. I have added these
> bugs to the next-kilo milestone.

Thanks

>> 3) an analysis of what it would take to be able to run
>> functional tests for zeromq on our CI infrastructure, not
>> necessarily the full tempest run or devstack-gate job, probably
>> functional tests we place in the tree with the driver (we will be
>> doing this for all of the drivers) + besides writing new
>> functional tests, we need to bring the unit tests for zeromq into
>> the oslo.messaging repository
>> 
>> Kapil Thangavelu started work on both functional tests for the
>> ZMQ driver last week; the output from the sprint is here:
>> 
>> https://github.com/ostack-musketeers/oslo.messaging
>> 
>> it covers the ZMQ driver (including messaging through the
>> zmq-receiver proxy) and the associated MatchMakers (local, ring,
>> redis) at a varying levels of coverage, but I feel it moves
>> things in the right direction - Kapil's going to raise a review
>> for this in the next couple of days.
>> 
>> Doug - has any structure been agreed within the oslo.messaging
>> tree for unit/functional test splits? Right now we have them all
>> in one place.
> 
> I think we will want them split up, but we don’t have an agreed
> existing structure for that. I would like to see a test framework
> of some sort that defines the tests in a way that can be used to
> run the same functional for all of the drivers as separate jobs
> (with appropriate hooks for ensuring the needed services are
> running, etc.). Setting that up warrants its own spec, because
> there are going to be quite a few details to work out. We will also
> need to participate in the larger conversation about how to set up
> those functional test jobs to be consistent with the other
> projects.

I guess we can put then up for review as is and then refactor to
support any future framework changes that come along.

>> 4) and some improvements that we would like to make longer term
>> 
>> a) Connection re-use on outbound messaging avoiding the current
>> tcp setup overhead for every sent message.  This may also bring
>> further performance benefits due to underlying messaging batching
>> in ZMQ.
> 
> This sounds like it would be a good thing to do, but making what we
> have work correctly and testing it feels more important for now.

Agreed - these are all futures.

>> b) Moving from tcp PUSH/PULL sockets between servers to
>> DEALER/DEALER (or something similar) to allow for heartbeating
>> and more immediate failure detection
> 
> I would need to understand how much of a rewrite that represents
> before commenting further.

Sorry - that item was a little hand-wavey - it could be minimal in
terms of impact but I would probably see it tied to a) so it might
involve the zmq-receiver moving towards zmq-proxy for both inbound and
outbound tcp connections.

>> 
>> c) Crypto support
> 
> There are some other discussions about adding crypto to messaging,
> and I hope we can do that without having to touch each driver, if
> possible.

That would be even better IMHO.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUGo8jAAoJEL/srsug59jDAMMP/0RCc3ElFC/E/UqZJrY+X2oE
YMB87TM06AX26wS2uKe7F7xEAsv+vMTcSK/FC13xGfd+xBTT13pHquBQjeHwUx2C
+2Fbp6QoLwbvZF69IWL0E/8M/KueGth+JrHRpPqQqK5OcuwmDbDOeq2eychDMg1w
p

[openstack-dev] OpenStack Icehouse milestone 1 packages for Ubuntu

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi All

As OpenStack Icehouse milestone 1 is now out, I thought it worth
updating everyone on Ubuntu activities during the Icehouse development
cycle.

For release, Ubuntu will be providing Icehouse packages for both
Ubuntu 14.04 and for Ubuntu 12.04 via the Ubuntu Cloud Archive (see
[0]).  Right now, icehouse-1 can be tested either using the current
Ubuntu development release (trusty) or using the icehouse-proposed
pocket in the Cloud Archive for Ubuntu 12.04, which can be enabled on
Ubuntu 12.04 systems by running:

 sudo add-apt-repository cloud-archive:icehouse-proposed

The packages are currently a straight refresh of the Havana packages
with any mandatory changes for Icehouse; expect more changes between
now and Icehouse milestone 2, including switching to the ML2 plugin in
Neutron as default and some re-jigging of the nova-compute-* packages
to make installs for off-host non-libvirt hypervisors a little easier
(see [1]).

You can report any bugs on these packages on 12.04 and trusty using
the ‘ubuntu-bug’ tool, for example:

ubuntu-bug neutron-server

Other notable upgrades alongside Icehouse include new versions of qemu
(1.7.x), Ceph (0.72.x) and Open vSwitch (2.0.x).  If you are using
Ubuntu trusty, you won’t need to use the openvswitch-datapath-dkms
package any longer - the 3.12 kernel currently shipping supports both
GRE and VXLAN overlay networking via the in-tree openvswitch kernel
module.

In addition to the milestone packaging that the Ubuntu Server team
pushes to the development release and the Cloud Archive, you can
always test with the latest trunk build packages and dependencies
using the OpenStack Ubuntu Testing PPA:

sudo add-apt-repository ppa:openstack-ubuntu-testing/icehouse

This PPA publishes packages for 12.04 and trusty as well.  They are
bleeding edge so may not always work - but hey - some folks like to
live on the edge!

Enjoy and happy testing!

James (on behalf of the Ubuntu Server Team)

- --
James Page
Technical Lead, Ubuntu Server Team

[0] http://wiki.ubuntu.com/ServerTeam/CloudArchive
[1]
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1311-openstack
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSqYQTAAoJEL/srsug59jDYzIP/2pN6Xs8dh0phrwXnaB3mHBM
48H6aoM4BRscTApYFscQO6aWNz+z0nSJhTI72YaRJOulKPgHtYlJgp7hTPOUPbLs
Qwo6QrsuSlmvgchBlFmYTWw3iAg2SX0Wz0UPFjWcg4Ru/qK+4+j8xkIonErO0Lnp
KVGi43nL4DtvJs4ji2+wnGV4op7ETLENbSzQJRD+cenUkawTp5Y5xamn+fxo9Vzq
I82/I5SYW6brUjGo3FbxxepHKwFnWjy/i4YiLa/GqjoRQ+cDY+Ayo3aFJN5J6VV8
XaxRJk3/Yf7nSaAGEbhr2J9r/3+ztafviSEoJMiTPrUMyieN57ihhnvGKLeVwuuS
QlAnNzgrhOwZf+sjdGgcbLml1d9Vto6G1+j79i/y0OE+Ke7EYxod8IToAELfrgNo
VPww0zfTgs1Ip224quGylrtWEdnG+f9awtj/fKU0qqECQ+/6igQPnaAvCI19KN+N
LJMN40yQeswcLW2VJ4PYRo3ZW/BKzB8IEq5H7Sdcl2jqSckjbCjnyLt6MwiIz6b2
XXNR/wHM1dWyWwmhAB7vLbo1+A4CMCBIW4LhS/CC7WEfnyYTAzosuuWrb+KQv+77
69e2Ir5CbdGEigea8XO+lPtgrzoBejyRrPBCVoGJZSUaMqQjmkh7k6WTpqwCOe7H
3pnhE0lJD5QBkAUk/XwG
=fRXG
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Call for Testing: Ubuntu OpenStack Kilo-1 development milestone

[James Page]

Hi Folks!

The Ubuntu Server Team is pleased to announce the general availability
of the first development milestone of the OpenStack Kilo release in
Ubuntu 15.04 development and for Ubuntu 14.04 LTS via the Ubuntu Cloud
Archive.

Ubuntu 14.04 LTS


For now, you can enable the Ubuntu Cloud Archive for OpenStack Kilo on
Ubuntu 14.04 installations by running the following commands:

  echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu
trusty-updates/kilo main" \
  | sudo tee /etc/apt/sources.list.d/cloud-archive.list
  sudo apt-get -y install ubuntu-cloud-keyring
  sudo apt-get update

The Ubuntu Cloud Archive for Kilo includes updates for Nova, Glance,
Keystone, Neutron, Cinder, Horizon, Swift, Ceilometer and Heat; Ceph
(0.87), RabbitMQ (3.4.2), QEMU (2.1), libvirt (1.2.8) and Open vSwitch
(2.3.1) back-ports from 15.04 development have also been provided.

Ubuntu 15.04 development


No extra steps required; just start installing OpenStack!  Keystone is
still pending update due to review of new dependencies by the Ubuntu
MIR team, but that should happen in the next few weeks.

New OpenStack components


This cycle we’ve also provided packages for Trove, Sahara and Ironic –
these projects are part of the integrated OpenStack release but remain
in Ubuntu universe for this development cycle, which means they won’t
get point release updates or security updates as part of ongoing
stable release maintenance once Ubuntu 15.04 and the Kilo Cloud
Archive for Ubuntu 14.04 LTS release.

NOTE: that if you use the Neutron FWaaS driver, you will need to
install the ‘python-neutron-fwaas’ package to continue using this
functionality; we will improve this situation in the packaging prior
to final release.

Reporting bugs
--

Let’s face it, as the first development milestone there are bound to
be a few bugs so please use the ‘ubuntu-bug’ tool to report any bugs
that you find – for example:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad.

Thanks and have fun!

Cheers

James

-- 
James Page
Technical Lead, Ubuntu Server and OpenStack Team
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org

__
OpenStack Development Mailing 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] [I18N] compiling translation message catalogs

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/10/14 18:00, Julie Pichon wrote:
> I'm adding a couple of people on cc: with an interest in Ubuntu and
> SUSE packaging: the Horizon team would love to have your opinion on
> this (it came up during our weekly meeting).
> 
> The current consensus is leaning toward removing the mo files for
> Juno RC2 (in a couple of days) rather than wait until Kilo, as this
> has been a pain point for (some/all?) distros for a while.

I'm in agreement that option a) is the best way to go; on the
assumption that compiling the message catalogs won't bring in
requirements for new dependencies, we can deal with that for rc2 in
Ubuntu for Juno.

> 
> Thank you,
> 
> Julie
> 
> On 01/10/14 17:04, Akihiro Motoki wrote:
>> Hi,
>> 
>> To display localized strings, we need to compile translated
>> message catalogs (PO files) into compiled one (MO files). I would
>> like to discuss and get a consensus who and when generate 
>> compiled message catalogs. Inputs from packagers are really
>> appreciated.
>> 
>> [The current status] * Horizon contains compile message catalogs
>> in the git repo. (It is just a history and there seems no strong
>> reason to have compiled one in the repo. There is a bug report on
>> it.) * Other all projects do not contain compiled message
>> catalogs and have only PO files.
>> 
>> [Possible choices] I think there are several options. (there may
>> be other options) (a) OpenStack does not distribute compiled
>> message catalogs, and only provides a command (setup.py
>> integration) to compile message catalogs. Deployers or
>> distributors need to compile message catalogs. (b) Similar to
>> (a), but compile message catalogs as a part of "pip install". (c)
>> OpenStack distributes compiled message catalogs as a part of the
>> release. (c1) the git repo maintains compiled message catalogs. 
>> (c2) only tarball contains compiled message catalogs
>> 
>> Note that the current Horizon is (c1) and others are (a).
>> 
>> [Pros/Cons] (a) It is a simplest way as OpenStack upstream. 
>> Packagers need to compile message catalogs and customize there
>> scripts. Deployers who install openstack from the source need to
>> compile them too. (b) It might be a simple approach from users
>> perspective. However to compile message catalogs during
>> installation, we need to install required modules (like babel or
>> django) before running installation (or require them as the
>> first citizen in setup.py "require"). I don't think it is much
>> simpler compared to option (a). (c1) Compiled message catalogs
>> are a kind of binary files and they can be generated from PO
>> files. There is no need to manage two same data. (c2) OpenStack
>> is downloaded in several ways (release tarballs is not the only
>> option), so I don't see much merits that the only tarball
>> contains compiled message catalogs. A merit is that compiled
>> message catalogs are available and there is no additional step
>> users need to do.
>> 
>> My preference is (a), but would like to know broader opinions 
>> especially from packagers.
>> 
>> Thanks, Akihiro
>> 
>> ___ OpenStack-dev
>> mailing list OpenStack-dev@lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>> 
- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUNTNeAAoJEL/srsug59jD2aoQAKAwvKgL0WLn8ZDqX5KGfX2R
OrTaNcozlNk2OXHgt2nDxOce6yQTbhh4yMJHsymOvgKj4+yOz5L78k9wkRgDmvqX
b6oiUIGjnQTiVQylT9FRuXicb/I5aoHOr2ki7LCHZ0QuABFCSC7noE/e4KnX2a0g
baaEC57UZa3aKepQ0PVQP50F5zGF5ux5jlP3oXtKtNjUL9l5bnTmwVgF8ymOYCZd
Q2fNU3CGUGG9LWwH6WmNJSKEkqGEP8+W7QEcXxT3/JhnVtYIJY/LehfLI8mUGu6o
geFfZqTYM5qOUrdCjFLJE8ayTE0jtM4VIUAX6xxkZNM4sdXdbH15N5UPqUFBRGsj
h/P/L/79qSMCt21eQBeaSDEKUvO6egG31tVpk7xTr6PIwRH8t5R+vXjPGjGqc78m
wdEhO8tMhEangeIbM5fKVKpQ9oqmp7SiI0sFzBS7eKRlB0VMbKCPegaBq8WJDbJq
/URCXYhgtFKTVCDpR5TUUkmhbHkc9NNcXQudJRnTscjy2VNmWI/QuSg7nHnP218H
cASWq1kUHvE7grncvaXyr3jPrKnSP2yVSqLsAOBYP5trb3ci9Sdyw+ajsPeLO8cB
bxEFPETfq5Oz/GEN6ojLr45gbqDuM5MY7pivD/y/4br/cmYtd8R8s/pD0kxn5o6Z
Www0BJtH1h1b2ChPlo+O
=CLi/
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][neutron] Fwd: Re: [Openstack-stable-maint] Neutron backports for security group performance

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Ihar

On 11/11/14 19:39, Ihar Hrachyshka wrote:
>> there is a series of Neutron backports in the Juno queue that are
>> 
>>> intended to significantly improve service performance when
>>> handling security groups (one of the issues that are main pain
>>> points of current users): - https://review.openstack.org/130101
>>> - https://review.openstack.org/130098 - 
>>> https://review.openstack.org/130100 - 
>>> https://review.openstack.org/130097 - 
>>> https://review.openstack.org/130105 The first four patches are
>>> optimizing db side (controller), while the last one is to avoid
>>> fetching security group rules by OVS agent when firewall is
>>> disabled.

In terms of putting some figures around how these proposed stable
patches help improve a Neutron based Juno cloud, I can provide some
metrics based on recent testing that Canonical did in-conjuction with HP.

The cloud we deployed was all based on Intel Atom Quad Core processors,
with 16G of RAM and SSD disk; 540 servers in total including 8 nova
controllers and 4 neutron controllers.  OpenStack Juno release on
Ubuntu 14.04.

With around 12,000 running instances, which was as far as I could push
a vanilla ML2/ovs based Juno cloud, the load on the 4 neutron
controllers was around 40 with CPU maxing out all of the time - which
pretty much mean't it was impossible to create any new instances due
to vif plugging timeouts in nova waiting for neutron to complete
network setup.

I patched in:

  https://review.openstack.org/#/c/130101/
  https://review.openstack.org/#/c/130098/
  https://review.openstack.org/#/c/130100/
  https://review.openstack.org/#/c/130105/

and re-ran the same test; the messaging load on the RabbitMQ server at
12,000 instances was considerably less in terms of volume, and the
load on the 4 neutron controllers was around 10 (vs 40) with CPU at
around 55->65% utilization - so still pretty busy, but a better
situation than without the patches.

My testing was quite synthetic (boot small instances until things
start to break) but it does illustrate the difference these patches make.

HTH

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUY5czAAoJEL/srsug59jDIJ8QAJAK8aWUSQGyPrcAqvKi+OE7
vS4NhVWog1ifubPcIpDstAoELHIfQVQKaryCN7oXAzQ0Yyp68DE68mw+o8rrly2S
25gPebORNath1BOJMMlv5iRS0lVN30cfmRrs9nfQ5bdAE6qkaPlofG9GsGRggCG2
feewRR9w+PFFQQ9NdsZ141FoQDtpLjhY095rEwzUhyah8spM2w2er2XiEJLHRTI/
HcJybUSX/Nu8OV4FJ6dn+pebWv1iWgzNOV/eqCYHf1Mx9G6HrB8ZQpv486LznyX1
PSNuiVMgUFcSWUcN1lFQSEe/ASW+G2t3/aEMKZBXiXsO3DTORtZ79oCTkzipkehj
18ztLr+nkCDrdGzbvkD6LWGt9F7MjTzsXao4RwGe/EiRBvcrvnHpkc5kfaW2aIb3
+rH8pcHpfaC04y7Zy492lFrkmrXn+73c2a+hS+gS3bMmQ1bcwF+QeeXunsMajgVo
CQW98n3HJI/jAjCBEbV5cmmw+BXQDWOHYlP+tZiAMC5Tnj42/9+K+KWZr+truhLK
cKGFlM+vaVsykAh9KIf1E/e6G72o/kihXDUnpx/mSk27sxDILEz9ItcQRJgpQCPN
cH3sIj+qG76NDqIhdLYs8LgyjwQI2SdOeSi+32oCCe3tnaI35FKKuRMI0oSP0HKn
3U7bekTsjXhlBWusW9Wb
=WaFI
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][neutron] Fwd: Re: [Openstack-stable-maint] Neutron backports for security group performance

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/11/14 17:43, Kevin Benton wrote:
> This is awesome. I seem to have misplaced my 540-node cluster. ;-)
> 
> Is it possible for you to also patch in
> https://review.openstack.org/#/c/132372/ ? In my rally testing of 
> port retrieval, this one probably made the most significant
> improvement.

Unfortunately not - our lab time on the infrastructure ended last week
and I had to (reluctantly) give everything back to HP.

That said, looking through all of the patches I applied to neutron, I
 had that one in place as well - apologies for missing that
information in my first email!.

Regards

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUZKy/AAoJEL/srsug59jDGa8QANJjKl8fyCmoE0FNZ0/xXnq0
qYu8u0yYm1SPya09KQaSmMUkMACjgiemjEKD/lICQASd/ROPMMRoqmbfiogDzDLZ
Si4U4CsYYy+EVnXQ3ozOopxbZHKNjjbTFBhNNvVeEQ1/sZpTHEdI6emwXlOuj6qP
Z36RmJpr1rQDhvvccywytVI2a42MbUnT53yjI4AKIc5TQBdPOW6QIr89sNNZM+jp
frNl40tCFo/SQU2TR3mmBXdXWYT5BAdNyAHBz/7TUNzSt5ZUXBSr/3lE2Vj69aZ6
ioMBwreeW+hV2NXYjLCpCAOsam7lz3qZjOC5DtZj4OrIy+J8ts73uHvPe2y0Gxr/
ANrbxPeRPp1uXAT4UPUqQZ4m2vYQVVwenc8cPQtzcXrJ9CF9ti8NrFnATtqdSf3a
2kWyKmJ1qd+6tValdImTFc/J7Vw/WPkTvoYXGAfszL6j0Ea6JGCvGCCvDOFZwG3o
NWGBaIVCAErlypDaqxQGfiUtsGWIrFfy52ufJ+YEc0L/pIq9ZUlrHE17LkUz2gC2
GTUbLYQ8+S+/b5suYzbthA+SHgc+Xzfzh+K+sCirEFzNaAhzJySvr7ssCRoKvs0d
QDoLaSGdwNDKjW/Y7O/eGHD1bz6RVfMxvky+pa8GZBHIp/YhEuBSNU3CNNEAt6El
/rWfIhMsjPtHlhHF245x
=Bnsb
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Denis

On 17/11/14 07:43, Denis Makogon wrote:
> During Paris Design summit oslo.messaging session was raised good 
> question about maintaining ZeroMQ driver in upstream (see section 
> “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
> know, good thoughts are comming always after. I’d like to propose
> several improvements in process of maintaining and developing of
> ZeroMQ driver in upstream.
> 
> Contribution focus. As we all see, that there are enough patches
> that are trying to address certain problems related to ZeroMQ
> driver.
> 
> Few of them trying to add functional tests, which is definitely
> good, but … there’s always ‘but’, they are not “gate”-able.

I'm not sure I understand you statement about them not being
"gate"-able - the functional/unit tests currently proposed for the zmq
driver run fine as part of the standard test suite execution - maybe
the confusion is over what 'functional' actually means, but in my
opinion until we have some level of testing of this driver, we can't
effectively make changes and fix bugs.

> My proposal for this topic is to change contribution focus from 
> oslo.messaging by itself to OpenStack/Infra project and DevStack 
> (subsequently to devstack-gate too).
> 
> I guess there would be questions “why?”.  I think the answer is
> pretty obvious: we have driver that is not being tested at all
> within DevStack and project integration.

This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.

> Also i’d say that such focus re-orientation would be very useful
> as source of use cases and bugs eventually. Here’s a list of what
> we, as team, should do first:
> 
> 1.
> 
> Ensure that DevStack can successfully:
> 
> 1.
> 
> Install ZeroMQ.
> 
> 2.
> 
> Configure  each project to work with zmq driver from 
> oslo.messaging.
> 
> 2.
> 
> Ensure that we can run successfully simple test plan for each 
> project (like boot VM, fill object store container, spin up volume,
> etc.).

A better objective would be able to run a full tempest test as
conducted with the RabbitMQ driver IMHO.

> ZeroMQ driver maintainers communityorganization. During design
> session was raised question about who uses zmq driver in
> production.
> 
> I’ve seen folks from Canonical and few other companies. So, here’s
> my proposals around improving process of maintaining of given
> driver:
> 
> 1.
> 
> With respect to best practices of driver maintaining procedure, we
> might need to set up community sub-group. What would it give to us
> and to the project subsequently? It’s not pretty obvious, at least
> for now, but i’d try to light out couple moments:
> 
> 1.
> 
> continuous driver stability
> 
> 2.
> 
> continuous community support (across all OpenStack Project that are
> using same model: driver should have maintaining team, would it be
> a company or community sub-group)
> 
> 2.
> 
> As sub-group we would need to have our own weekly meeting. Separate
> meeting would keep us, as sub-group, pretty focused on zmq driver
> only (but it doesn’t mean that we should not participate in regular
> meetings). Same question. What it would give us and to the project?
> I’d say that the only one valid answer is: we’d not disturb other
> folk that are not actually interested in given topic and in zqm
> drive too.

I'd prefer that we continue to discuss ZMQ on the broader
oslo.messaging context; I'm keen that the OpenStack community
understands that we want ZMQ to be a first tier driver like qpid and
rmq, and I'm not convinced that pushing discussion out to a separate
sub-group enforces that message...

> So, in the end, taking into account words above i’d like to get 
> feedback from all folks. I’m pretty open for discussion, and if
> needed i can commit myself for driving such activities in
> oslo.messaging.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUagWDAAoJEL/srsug59jDWncP/2PVkA3tDHxLILjdyXKdLLy6
fsj5yovho45T9LtSrLXD1Y+CT3pQqGDnglB+J8kUBkX56zJLWzSH1szWfRo5Y4Ms
kI0c3K8LxJ6PT4+j/A5JzNt37IhAwBTJ25QcRdzAUgV06IZ3F9ctz9F9lW1GDx/q
u5XvctYacKWhXH/Z/5Y2g3VE2aJSZNlgLA3PxLZeUEQaREj7XeC5x77FZbBYHVI6
E8E8B2H5nf+wln80zIm5rax3vzGh0rZVT/fgUgVcQan33XaFl64zrimjhEUXHUVF
QHIVJ4PNVklqMAEliAq0JMe6ewo1rgbS6DOcB8yOD3RWNo+d/MwSbYiwM/iXI9ya
DpqXK0HVfSbXgoAAqNl2eP5TfvZCtlRk1h3hqhc+843c7i+i2psMZ2mVN6LeJKdt
7EvwY8xQErjKSbsmEjtV069ajjipP3hnmhyUwwJiFM2q8eKMIWRn+WDol88+f4Ke
NmguGjNzKkqqvWSS/IJVT+qHYEsm3G

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/11/14 09:01, Denis Makogon wrote:
> I'm not sure I understand you statement about them not being 
> "gate"-able - the functional/unit tests currently proposed for the
> zmq driver run fine as part of the standard test suite execution -
> maybe the confusion is over what 'functional' actually means, but
> in my opinion until we have some level of testing of this driver,
> we can't effectively make changes and fix bugs.
> 
> I do agree that there's a confusion what "functional testing"
> means. Another thing, what the best solution is? Unit tests are
> welcome, but they are still remain to be units (they are using
> mocks, etc.) I'd try to define what 'fuctional testing' means for
> me. Functional testing in oslo.messaging means that we've been
> using real service for messaging (in this case - deployed 0mq). So,
> the simple definition, in term os OpenStack integration, we should
> be able to run full Tempest test suit for OpenStack services that
> are using oslo.messaging with enabled zmq driver. Am i right or
> not?

0mq is just a set of messaging semantics on top of tcp/ipc sockets; so
its possible to test the entire tcp/ipc messaging flow standalone i.e.
without involving any openstack services.  That's what the current
test proposal includes - unit tests which mock out most things, and
base functional tests that validate the tcp/icp messaging flows via
the zmq-receiver proxy.  These are things that *just work* under a tox
environment and don't require any special setup.

This will be supplemented with good devstack support and full tempest
gate, but lets start from the bottom up please!  The work that's been
done so far allows us to move forward with bug fixing and re-factoring
that's backed up on having a base level of unit/functional tests.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUajaZAAoJEL/srsug59jDm2wP/1xW99gc/63CXnNowJLwgCAK
AflhWs4SAUSF0VizOFoys6j1ApjAwWDG33B927REH/YDNwmAd7PgHRilgcaBjR5w
pgaPRctCHPpWtJCWRCAmgkogqJotN3gTDKORxRNaWo9otzjQQbyPP5sEzuLl86/8
0n9KjwhjdJV42fcoKYvWt18uvz9yVOQLlPqj0WhAuzfpeP/5ZkXkd/dOvh6rwJnk
wc+ZExPBhdeMNwaJFPZvle++Ki6tZCV8P8+Be5rqTZxdnGxoct72YnIohW48E9Nu
1sjdJCg42vxIMZi8NfkJDDfTBWzOmkab2jcViIJd9ycTn8CT/e62ZK8nN/hnIjla
qU8pdRxNkY7xY3AuVoTWYRZGAon+Pp6Xw3J+lh7xUYukKtP/PaN+PjLCmVYrfca0
JQnc8N5bLfcZkz/tx8R09hxqV7cpaRZh/lM6D62XEMRQJ7y9rcUIaJQnHbsmqLw9
lwriXjNE/77eyttQlGnItyBZrTFjCFED9zg6ihK5w0DNXQr3CbIvlgCjiWkXfxDD
1QK05SbsukSlnO+Aqfs/HNICMdiZmqxcqcUcVs/XnKXf5Bi/Y/P0haLb43nFoa3E
FaOYvY/T5HSJDvrFK6+kzPgT2zF3sWy4bZjRwKLl8GM8Mm7K65nfd5APhVCnQq5X
yZOvpJehduiy6W/lQgzk
=HAiM
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/11/14 00:55, Denis Makogon wrote:
> 
> 
> So if zmq driver support in devstack is fixed, we can easily add a 
> new job to run them in the same way.
> 
> 
> Btw this is a good question. I will take look at current state of
> zmq in devstack.

I don't think its that far off and its broken rather than missing -
the rpc backend code needs updating to use oslo.messaging rather than
project specific copies of the rpc common codebase (pre oslo).
Devstack should be able to run with the local matchmaker in most
scenarios but it looks like there was support for the redis matchmaker
as well.

If you could take some time to fixup that would be awesome!

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIbBAEBCAAGBQJUa03HAAoJEL/srsug59jDdZQP+IeEvXAcfxNs2Tgvt5trnjgg
cnTrJPLbr6i/uIXKjRvNDSkJEdv//EjL/IRVRIf0ld09FpRnyKzUDMPq1CzFJqdo
45RqFWwJ46NVA4ApLZVugJvKc4tlouZQvizqCBzDKA6yUsUoGmRpYFAQ3rN6Gs9h
Q/8XSAmHQF1nyTarxvylZgnqhqWX0p8n1+fckQeq2y7s3D3WxfM71ftiLrmQCWir
aPkH7/0qvW+XiOtBXVTXDb/7pocNZg+jtBkUcokORXbJCmiCN36DBXv9LPIYgfhe
/cC/wQFH4RUSkoj7SYPAafX4J2lTMjAd+GwdV6ppKy4DbPZdNty8c9cbG29KUK40
TSCz8U3tUcaFGDQdBB5Kg85c1aYri6dmLxJlk7d8pOXLTb0bfnzdl+b6UsLkhXqB
P4Uc+IaV9vxoqmYZAzuqyWm9QriYlcYeaIJ9Ma5fN+CqxnIaCS7UbSxHj0yzTaUb
4XgmcQBwHe22ouwBmk2RGzLc1Rv8EzMLbbrGhtTu459WnAZCrXOTPOCn54PoIgZD
bK/Om+nmTxepWD1lExHIYk3BXyZObxPO00UJHdxvSAIh45ROlh8jW8hQA9lJ9QVu
Cz775xVlh4DRYgenN34c2afOrhhdq4V1OmjYUBf5M4gS6iKa20LsMjp7NqT0jzzB
tRDFb67u28jxnIXR16g=
=+k0M
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Ilya

On 18/11/14 02:45, Ilya Pekelny wrote:
> Thank you, Eric, for your descriptions!
> 
> I'm very new to rpc and oslo.messaging. So I can be wrong in the
> idea of how it all designed and I can be wrong in a particular
> formulations. But I'm highly motivated in improvement of the
> rpc/oslo.messaging knowledge. I'm going to clarify all your
> descriptions and come back with updated propositions.
> 
> Thank you, Russell, for your proposition!
> 
> I'll pay attention to AMQP 1.0 as soon as possible. I'm not sure I
> can take it all to work but for sure I'll have an understanding
> about AMQP 1.0 in a nearest future.

As Eric detailed, the zmq driver does not implement a centralized
broker design.  I put together this diagram:

https://docs.google.com/drawings/d/1A3PyBbZArzxRa2s4gGMIu1VYhsmc1FXWYbniSkA5_TU/edit?usp=sharing

when my team reviewed the existing design with Pieter Hintjens (ZeroMQ
upstream) in September to articulate how the driver functions with the
zmq-reciever and openstack processes.  I have an action item to
document that within the oslo.messaging codebase so its a bit more
accessible and with the actual code.

I think that the design is sound but there are a number of
optimizations and features that we did discuss as improvements:

1) Outbound messaging connection re-use - right now every outbound
messaging creates and consumes a tcp connection - this approach scales
badly when neutron does large fanout casts.

2) PUSH/PULL tcp sockets - Pieter suggested we look at ROUTER/DEALER
as an option once 1) is resolved - this socket type pairing has some
interesting features which would help with resilience and availability
including heartbeating.

3) Security options including encryption; this would require some
distribution work in Ubuntu right now as zeromq is not built with this
feature enabled.

I think for this cycle we really do need to focus on consolidating and
testing the existing driver design and fixing up the biggest
deficiency (1) before we consider moving forward with lots of new
features.


- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUa1GuAAoJEL/srsug59jDrOcP/isK148CV+wHwoue12f/oFQb
Ri7SjP8NfPhkX9izRbLC1PyrMZvFcnf5qTJaC9PZJbREmD5IYawDBP5Vs68aHFO+
s2t/FtuVrrdxqWuFF181XPfdB6pf6dRCjRp3NCIQL+x1wIJ0n828T1fhhAg419ki
17ccBhpoVpFPnqyaTbLsvYzumuLXXTSJWn523gQ6mOsYyRUONbP4LudFmzj/AVCd
XzzS/Aq3YM0HeBqTMgiLlqzDqFptim/P+LZctOeUzkq+VNBAwLV8yBUQ5xQmDhrC
38LDLaMOzmXiQPvizUx9duV/TKxaBJf1Uqf+IlZStm2GSwnRbw3YK00L0tPR5t1n
IJjsgZz6KZDpWhZ6u5GwL9tNKtMiaAnVcSQ6DJmxLOao5VMEPhY/442hmrSU1MHl
MsE8FyN8uTQM9Byo+Wfg1+A52+3Gr2pH489XhhA8ROqCMIA3bRizEMcI14kb+GbA
wA+q7hFvFrwaUC18YeCN2tDibMmq6PeT9cUSMNB45MhSd130kCMUy6DrhagW5mU/
UXr/25cMvbVqF+0UjssPzom1fJ8KYK7tgbNqc+sExMqZFbJMG1yMCm7Zp7ei+xMc
tEs5O58BsMEu2tx7y3UjEJwFuQPUc0FkYKGXyx6ZT9iyfMrFSdY2CSp3Cl5gXc2Z
g4FCigKTr7IXew6bdzxi
=MUSc
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Havana RC1 available in the Ubuntu Cloud Archive for 12.04

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Folks

I've just finishing promoting all of the Havana RC1 packages and
associated dependencies to the Ubuntu Cloud Archive for Ubuntu 12.04 LTS.

For details of how to use the Ubuntu Cloud Archive for Havana, please
refer to:

  https://wiki.ubuntu.com/ServerTeam/CloudArchive

The latest packages are all now in the updates pocket (they have been
kicking around in proposed for a few days now - we where just waiting
on Swift so that we could complete final smoke testing).

You can track which versions of what are where here:


http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/havana_versions.html

Please use the 'ubuntu-bug' tool to report bugs back to Launchpad, for
example:

  ubuntu-bug nova-compute

This will log the bug against the right project in launchpad and
collect some basic information about which versions of packages you
are using.

Enjoy

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSV/NHAAoJEL/srsug59jDT+UP/R7EJcOW63KS7l33/7+GFtuu
vAIYP/WAlUgC6ShUDD2TfFvKFCQ7HA7Ctw5qB5MjvTBH8ZV43/IDiYaww0gyq6ah
BIWmiJhu+6Vq/KRb93fYenpDPV5oFnCy5jbtZnN6DmwEsCcYPanzI9GToyLDxR1n
dzTO6im3HCcm55j+cAd3ehCmkcy4GHk+5pJqKtssGRCKHaRTl2YJ3XaGKTDlDFj1
P967dJFeWr/b3AJif7siKapJSOoJH5wvhwmaEu44bkRfZp8kOdEIEXP19fJKchZi
+TdNyyjf1DWJcMTdHxEbDJ+oCH7bfehekqhg0y8Y2ASdkuhbntjXEEVS9Zaj1m3F
GVTeM/dvumG4YYdAWllF/9i480frifBr7s/5QyTR63seOOBgyb8PRWanDqv8+OGk
4VP6km+U4Q2fO3BsD04YhR0NAcV0wZvc8B2Hn+ut+mdsxLellMhlgew//S/Jj6SW
ict/xuw7bXgHk3ROtnT48WOBEoNxqKxlZA+WntFzn5d4lbqpR2HuLXCtOOU6m1Jy
QDjBAwpQ1V8Bu1qI2ZiVT55S8YhU1EMLRqO4E85Wg/SstemXLj4jC8jTMi5c3hWl
wHMCmJhLZMLq3N2b4ojKmYSlfvfXwGyhSr9hvtJSol8dhRpGw+meVUc2eWeCc7kz
9E7YADmdKW1DTUx+KHbI
=VLr+
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Havana RC2's available in the Ubuntu Cloud Archive for 12.04

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Folks

RC2's for nova, cinder, glance, heat and neutron should be available
in the Havana Cloud Archive for Ubuntu 12.04 in the next hour or so - see:

http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/havana_versions.html

For details of how to use the Ubuntu Cloud Archive for Havana, please
refer to:

  https://wiki.ubuntu.com/ServerTeam/CloudArchive

Cheers

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSWswvAAoJEL/srsug59jDoV8P/Ra90ial4XUh6CYJqLK7bdTN
qmpQertlufIb86r2cklz6sdVvPJ5pMkxSRLl5ugc+rI4M9T1GNGElS4rtm8Eo5+t
M8ABeXqlcmtr3kkyGvanSVBE707CFVXp89jyDFaoxPUC9PB+6mAx97TxfT7suRIJ
8pGewNUO4bgYMSJsSi3hqK0tq5hVU9a3cUzQCNOB9cOejnLxYOuGVoFiMagTz7gR
L4Z/z6DQZnzUhxGAJeqok0iJK8zghxRO6zDycJM1E94MvbYq80vfKf/6xg5Yv4UZ
T+75EkJ2cupLanHp4zFc/MzOoakuKFIibsKODefzh2YUtvUK383hjWtgfz4KZbBg
fmY9mZqHToWMKCbwGkNvvzQOkCec7jbtfZuCFevHZ5rbtTe3aTspy+sHKTbN1H4j
exCjJpx8RLNTdCvZdc22AkH437DFeyI0LS1oZqfVZZ1E1UlFtqv0xpIGEGMKZEMN
pe+c2v7fNfAT1r+pX3NE9nBLOQM5BjW/vWq4GTAfqt2Q4YEvGQd51WzE1DQKELlj
Q/v5UJzScQuP60kqec7kVkjxTQFsV9ZkFuu6Gj17t+lcGcxnEHI+Vysmar/dnLc8
+815mR3d99nvmiXhgYnncFB8PJOZPmuTN39NaCALbb2xFYYGg3wx8ZTePnLD14IE
hrzh3lPEAmq0cHy9K6I8
=rtrL
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

[James Page]

Hi Markus

On Tue, Nov 17, 2015 at 7:10 PM, Markus Zoeller  wrote:

> Background
> ==
> The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> libvirt. Among others to solve bug [2], one of our oldest ones. The
> funny part is, that this libvirt feature is still in development. This
> was a trigger to see if we can create a gate job which utilizes the
> latest, bleeding edge, version of libvirt to test such features. We
> discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> get some feedback here. The summary of the idea is:
> * Create a custom repo which contains the latest libvirt version
> * Enhance Devstack so that it can point to a custom repo to install
>   the built libvirt packages
> * Have a nodepool image which is compatible with the libvirt packages
> * In case of [1]: check if tempest needs further/changed tests
>
> Open questions
> ==
> * Is already someone working on something like that and I missed it?
> * If 'no', is there already a repo which contains the very latest
>   libvirt builds which we can utilize?
>

What are your requirements for libvirt and qemu?  The Liberty UCA for
Ubuntu has the following versions:

  libvirt: 1.2.16
  qemu: 2.3

if that's useful these can be added to any Ubuntu 14.04 system using:

  sudo add-apt-repository cloud-archive:liberty

versions will be updated during Xenial development to later releases which
will be backported to 14.04 as part of the Mitaka UCA.
__
OpenStack Development Mailing 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] [networking-ovs-dpdk]

[James Page]

Hi All

Reading through this thread I thought participants might be interested to
know that Ubuntu now provides a DPDK enabled Open vSwitch package in Ubuntu
15.10 and for Ubuntu 14.04 using the Liberty UCA; you can use it as follows:

   sudo add-apt-repository cloud-archive:liberty  # not required for 15.10
   sudo apt-get update
   sudo apt-get install openvswitch-switch-dpdk
   sudo update-alternatives --set
ovs-vswitchd /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk
   sudo service openvswitch-switch restart

DPDK configuration is passed through OVS using
/etc/default/openvswitch-switch (read for details).  The dpdk package also
provides some basic configuration mechanisms for hugepages and binding
networking adapters to userspace in /etc/dpdk.

This is a first packaging release and is experimental - please do provide
feedback on what you do and don't like about it...

On Wed, Nov 18, 2015 at 6:12 AM, Prathyusha Guduri <
prathyushaconne...@gmail.com> wrote:

> Thanks a lot Sean, that was helpful.
>
> Changing the target from ivshmem to native-linuxapp removed the error and
> it doesn't hang at creating external bridge anymore.
> All processes(nova-api, neutron, ovs-vswitchd, etc) did start.
>
> Thanks,
> Prathyusha
>
> On Tue, Nov 17, 2015 at 7:57 PM, Mooney, Sean K 
> wrote:
>
>> We mainly test with 2M hugepages not 1G however our ci does use 1G pages.
>>
>> We recently noticed a different but unrelated related issue with using
>> the ivshmem target when building dpdk.
>>
>> (https://bugs.launchpad.net/networking-ovs-dpdk/+bug/1517032)
>>
>>
>>
>> Instead of modifying dpdk can you try
>>
>> Changing the default dpdk build target to x86_64-native-linuxapp-gcc.
>>
>>
>>
>> This can be done by  adding
>>
>>
>>
>> RTE_TARGET=x86_64-native-linuxapp-gcc to the local.conf
>>
>> And removing the following file to force a rebuild
>> “/opt/stack/ovs/BUILD_COMPLETE”
>>
>>
>>
>> I agree with your assessment though this appears to be a timing issue in
>> dpdk 2.0
>>
>>
>>
>>
>>
>>
>>
>> *From:* Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
>> *Sent:* Tuesday, November 17, 2015 1:42 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [networking-ovs-dpdk]
>>
>>
>>
>> Here is stack.sh log -
>>
>>
>> 2015-11-17 13:38:50.010 | Loading uio module
>> 2015-11-17 13:38:50.028 | Loading DPDK UIO module
>> 2015-11-17 13:38:50.038 | starting ovs db
>> 2015-11-17 13:38:50.038 | binding nics
>> 2015-11-17 13:38:50.039 | starting vswitchd
>> 2015-11-17 13:38:50.190 | sudo RTE_SDK=/opt/stack/DPDK-v2.0.0
>> RTE_TARGET=build /opt/stack/DPDK-v2.0.0/tools/dpdk_nic_bind.py -b igb_uio
>> :07:00.0
>> 2015-11-17 13:38:50.527 | sudo ovs-vsctl --no-wait --may-exist add-port
>> br-eth1 dpdk0 -- set Interface dpdk0 type=dpdk
>> 2015-11-17 13:38:51.671 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:52.685 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:53.702 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:54.720 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:55.733 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:56.749 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:57.768 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:58.787 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:38:59.802 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:00.818 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:01.836 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:02.849 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:03.866 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:04.884 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:05.905 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:06.923 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:07.937 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:08.956 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:09.973 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:10.988 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:12.004 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:13.022 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:14.040 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:15.060 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:16.073 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:17.089 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:18.108 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:19.121 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:20.138 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:21.156 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:22.169 | Waiting for ovs-vswitchd to start...
>> 2015-11-17 13:39:23.185 | Waiting for ovs-vswitchd to start...
>>
>>
>>
>> On Tue, Nov 17, 2015 at 6:50 PM, Prathyusha Guduri <
>> prath

Re: [openstack-dev] [networking-ovs-dpdk]

[James Page]

Hi Sean

On Wed, Nov 18, 2015 at 12:30 PM, Mooney, Sean K 
wrote:

> Hi james
>
> Yes we are planning on testing the packaged release to see if it is
> compatible with our ml2 driver and the
>
> Changes we are submitting upstream. If it is we will add a use binary flag
> to our devstack plugin to skip the
>
> Compilation step and use that instead on 15.10 or 14.04
> cloud-archive:liberty
>

Excellent.


> As part of your packaging did ye fix pciutils to correctly report the
> unused drivers when an interface is bound
>
> The dpdk driver? Also does it support both igb_uio and/or vfio-pci drivers
> for dpdk interface?
>

Re pcituils, we've not done any work in that area - can you give an example
of what you would expect?

The dpdk package supports both driver types in /etc/dpdk/interfaces - when
you declare an adapter for use, you get to specify the module you want to
use as well; we're relying the in-tree kernel drivers (uio-pci-generic and
vfio-pci) right now.


>
>
> Anyway yes I hope to check it out and seeing what ye have done. When
> ovs-dpdk starts getting packaged in more operating systems
>
> We will probably swap our default to the binary install though we will
> keep the source install option as it allows us to work on new features
>
> Before they are packaged and to have better performance.
>

That sounds sensible; re 'better performance' - yeah we do have to baseline
the optimizations at compile time right now (ssse3 only right now) , but I
really hope that does change so that we can move to a runtime CPU feature
detection model, allowing the best possible performance through the
packages we have in Ubuntu (or any other distribution for that matter).
__
OpenStack Development Mailing 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] [charms] Juju Charms for OpenStack

[James Page]

Hi All

tl;dr Juju is a great way of deploying OpenStack, and we'd like the
OpenStack Charms for Juju to become a official OpenStack Project

read on if you want the full details

Juju [0] is a service modelling tool that's been around since about 2010;
developed primarily by Canonical, Juju takes a high level approach to
modelling services and the relations between them (think cinder,
neutron-api, nova-cloud-controller), with the details on exactly how each
of those services is installed, configured, scaled-up, scaled-down, HA'ed
etc.. implemented by a charm for each of the services that form part of a
model;  Juju uses underlying providers (responsible for managing compute,
storage and network resources) to translate the model onto actual machine
resources - in the context of OpenStack, the MAAS (metal-as-a-service [1])
provider is used to deploy an OpenStack model, using the OpenStack Charms,
to a combination of physical servers and LXD containers running on those
servers.

The OpenStack Charms have been around for about the same time as Juju; I
think the first release we supported was OpenStack Diablo, and we've
updated, redesigned and re-factored the charms to support every OpenStack
release on Ubuntu since then.

The OpenStack Charms are a core part of the Ubuntu OpenStack teams approach
to distributing OpenStack on Ubuntu (we use them for all of our deployment
and testing CI, as well as for deploying production OpenStack Clouds at
Canonical's customers). As a result when OpenStack releases we've always
had aligned support in Ubuntu and the OpenStack charms for the latest
release.

The OpenStack charms (26 of them including some things not specifically
OpenStack such as Ceph, Percona XtraDB Cluster and RabbitMQ) are written in
Python; the code base has evolved a-lot over the years (once upon a time
they where bash scripts), as has the approach to writing best practice
charms, and we expect new OpenStack charms to take a slightly different
approach to charm authoring which should make writing a new OpenStack charm
much more lightweight (see [3]).

We migrated development to OpenStack project infrastructure (from its
original home in Launchpad and Bazaar branches) around 4 months ago at the
request of the TC from our original request to be formally recognised as an
OpenStack project; we now have some history that's readily re-viewable so
I've restored our request to become a formal OpenStack project:

 https://review.openstack.org/224797

The community of developers around the charms is not as diverse as I would
like, but we've had a number of contributions from developers at SDN and
storage vendors (who are also maintaining charms for their own solutions)
as well as contribution from CloudBase for enabling support for Microsoft
Hyper-V in a Juju deployed OpenStack Cloud (Juju and MAAS can deploy
WIndows machines as well).

We have some outstanding work to consolidate developer and user
documentation around the OpenStack charms, which the team currently expect
to complete in the next few months.

Cheers

James

[0] https://jujucharms.com/
[1] https;//maas.ubuntu.com/
[2] https://jujucharms.com/openstack
[3]
https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md
__
OpenStack Development Mailing 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] [charms] Renaming openvswitch-odl -> openvswitch

[James Page]

Hi All

The current openvswitch-odl charm is designed for use with
nova-compute/neutron-gateway and the odl-controller charm, but it declares
and configures OVS in such a way that I think it has broader applicability
than just OpenDayLight; specifically it looks like it would also work with
ONOS which configures the OVS manager in exactly the same way as for ODL.

I'd like to proposed renaming the openvswitch-odl charm to just openvswitch
to support this generalisation of its use.

Thoughts?
__
OpenStack Development Mailing 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] [charms] Re-licensing OpenStack charms under Apache 2.0

[James Page]

Hi

We're currently blocked on becoming an OpenStack project under the big-tent
by the licensing of the 26 OpenStack charms under GPL v3.

I'm proposing that we re-license the following code repositories as Apache
2.0:

  charm-ceilometer
  charm-ceilometer-agent
  charm-ceph
  charm-ceph-mon
  charm-ceph-osd
  charm-ceph-radosgw
  charm-cinder
  charm-cinder-backup
  charm-cinder-ceph
  charm-glance
  charm-hacluster
  charm-heat
  charm-keystone
  charm-lxd
  charm-neutron-api
  charm-neutron-api-odl
  charm-neutron-gateway
  charm-neutron-openvswitch
  charm-nova-cloud-controller
  charm-nova-compute
  charm-odl-controller
  charm-openstack-dashboard
  charm-openvswitch-odl
  charm-percona-cluster
  charm-rabbitmq-server
  charm-swift-proxy
  charm-swift-storage

The majority of contributors are from Canonical (from whom I have
permission to make this switch) with a further 18 contributors from outside
of Canonical who I will be directly contacting for approval in gerrit as
reviews are raised for each repository.

Any new charms and supporting repositories will be licensed under Apache
2.0 from the outset.

Cheers

James
__
OpenStack Development Mailing 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] [charms] inclusion of charm-helpers (LGPL licensed)

[James Page]

Hi All

Whilst working on the re-licensing of the OpenStack charms to Apache 2.0,
its apparent that syncing and inclusion of the charm-helpers python module
directly into the charm is not going to work from a license compatibility
perspective. charm-helpers is LGPL v3 (which is OK for a runtime dependency
of an OpenStack project - see [0]).

We already have a plan in place to remove the inclusion of charm-helpers
for execution of functional tests, but we need to come up with a solution
to the runtime requirement for charm-helpers, preferably one that does not
involve direct installation at deploy time from either pypi or from
lp:charm-helpers.

Thoughts? ideas?

Cheers

James

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

Re: [openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)

[James Page]

Hi Billy

On Thu, 30 Jun 2016 at 17:24 Billy Olsen  wrote:

> I suspect that the reactive charming model wouldn't have this issue
> due to the ability to essentially statically link the libraries via
> wheels/pip packages. If that's the case, it's likely possible to
> follow along the same lines as the base-layer charm and bootstrap the
> environment using pip/wheel libraries included at build time. As I see
> it, this would require:
>
> * Updates to the process/tooling for pushing to the charm store
> * Update the install/upgrade-charm hook to bootstrap the environment
> with the requirements files
> * If using virtualenv (not a requirement in my mind), then each of the
> hooks needs to be bootstrapped to ensure that they are running within
> the virtualenv.
>

I was thinking of something along those lines as well.  I'll spike on
something this week to figure out exactly how this might work.


> To make life easier in development mode, the charms can downla
> build step before deployment, though certainly for the published
> versions the statically linked libraries should be included (which,
> from my understanding, I believe the licensing allows and why the
> reactive charming/layered model wouldn't have this issue).
>

That sounds like a neat idea (although building out a layered charm is
pretty easy as well).
__
OpenStack Development Mailing 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] [Charm][Congress] Upstreaming JuJu Charm for Openstack Congress

[James Page]

Hi Bryan

On Tue, 5 Jul 2016 at 21:21 SULLIVAN, BRYAN L  wrote:

> I've been working in the OPNFV (https://wiki.opnfv.org/) on a JuJu Charm
> to install the OpenStack Congress service on the OPNFV reference platform.
> This charm should be useful for anyone that wants to install Congress for
> use with an OpenStack deployment, using the JuJu tool. I want to get the
> charm upstreamed as an official openstack.org git repo similar to the
> other repos for JuJu Charms for OpenStack services. I participate in the
> Congress team in OpenStack, who don't know the process for getting this
> charm upstreamed into an OpenStack repo, so I am reaching out to anyone on
> this list for help.
>

I can help you with that as I did most of the project-config changes for
the original move of OpenStack charms to git/gerrit a few months back.


> I have been working with gnuoy on #juju and narindergupta on #opnfv-joid
> on this. The charm has been tested and used to successfully install
> Congress on the OPNFV Colorado release (Mitaka-based, re OpenStack). While
> there are some features we need to continue to work on (e.g. Horizon
> integration), the charm is largely complete and stable. We are currently
> integrating it into the OPNFV CI/CD system through which it will be
> regularly/automatically tested in any OPNFV JuJu-based deployment (with
> this charm, Congress will become a default service deployed in OPNFV thru
> JuJu).
>

That all sounds awesome; it would also be great to get that system doing
testing of reviews and providing feedback to proposed changes; we can cover
some of that using Canonical CI (you'll notice that feeding back on reviews
on the charms already being developed under git/gerrit), but having other
3rd party CI systems provide feedback would also be great!.

Any pointers on how to get started toward creating an OpenStack git repo
> for this are appreciated.
>

https://review.openstack.org/#/c/323716/ is probably a good start; this was
for the hacluster charm which got missed during the original migration.

You can add an additional field to the gerrit/projects.yaml entry to detail
the repository to do a one-time import from:

 upstream: https://github.com/gnuoy/charm-congress


Lets make sure we get any outstanding changes merged into that repository
first, or we can use your git repo for the one-time import if that's easier
for now.

I'd really love to have congress as part of the OpenStack Charms project
(we're currently working towards official project status at the moment) but
I'd also like to ensure that you're engaged directly with reviews and
changes to the congress charm specifically, so I think its worth having a
slight different ACL configuration that includes the core charm acl config,
but also adds an additional charms-congress-core group with permissions to
Code-Review: +2 and Workflow: +1 for congress charm repository.

Does that make sense? you can reach out to me in #openstack-charms to
discuss in more detail if you like.

Cheers

James
__
OpenStack Development Mailing 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] Juju Charm Usability/Functionality Enhancements

[James Page]

Hi James

On Wed, 6 Jul 2016 at 18:52 James Beedy  wrote:

> I've a few things I want to bring up concerning usability/functionality in
> nova-cloud-controller and openstack-dashboard.
>
> 1. Request-timeout configurability for openstack-dashboard.
> - Everyone who accesses horizon asks me for this. I think it would be
> smart to set the timeout to the keystone token session timeout value.
> - I've filed a feature request/bug, and proposed a merge for this in
> the past, to no avail. This is a must for usability, and so simple to add.
> What gives?
>

visibility of merges across a large number of charms in launchpad was never
good so things did get missed; I've had a dig but can't find either a bug
or a merge against the old launchpad bzr branches; this sounds like a
useful feature - it would be helpful if you could raise a bug and then we
can workout how that fits into the next 3 months of charm delivery.


> 2. 'cross_az_attach=True'
> - Without "cross_az_attach=True" under the cinder context in
> nova.conf, live migration across availability_zones, alongside a handful of
> other critical ops fail.
> - This is a critical config param, the absence of which has blocked me
> on multiple levels for a long time now.
> - I've previously filed a bug/feature request for this, and also have
> proposed a merge that adds this functionality.
> - This is critical. ATTN HERE ASAP, PLEASE!
>

Already on my list to review this bug:


https://bugs.launchpad.net/charms/+source/nova-cloud-controller/+bug/1599289

again I can't find a merge on Launchpad (see [1]) but we'll see if we can
fit this into the next 7 days of dev prior to the feature freeze for the
16.07 charm release at the end of the month.

Cheers

James

[1]
https://code.launchpad.net/~openstack-charmers-archive/charms/trusty/nova-cloud-controller/next/+merges
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[James Page]

On Sun, 8 May 2016 at 15:58 Monty Taylor  wrote:

> On 05/08/2016 03:45 AM, Steve Kowalik wrote:
> > On 08/05/16 08:11, lương hữu tuấn wrote:
> >> Hi,
> >>
> >> @Robert: I was successful to update the kernel without change the image.
> >
> > But that was Robert's point entirely. Installing the kernel will work
> > fine, but it does not get you running that kernel -- also like Robert
> > said, you need to change the image to run a different kernel than what
> > it has installed.
> >
>
> We will be changing our images this cycle to Xenial from Trusty. I do
> not believe we have any intention of installing backported wily kernels
> in our trusty images, as what we want to test on them is Trusty.
>
> However, the Xenial transition should be happening soon enough - so
> things that need a newer kernel this release can happily just require
> Xenial images for testing.
>
> I think the question of why/how kolla grew a dependency on a newer
> kernel than what trusty has is worth checking. As of right now, trusty
> kernels are the newest thing supported in the gate.
>

Probably worth noting that trusty does provide hardware enablement
(sometimes referred to as HWE) kernels from newer Ubuntu releases in
archive; however they are not used as the base for Ubuntu Cloud Images
(which just use the release kernel version for 14.04 which is 3.13) and
evidently the trusty images in gate.
__
OpenStack Development Mailing 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] [tc] supporting Go

[James Page]

On Mon, 9 May 2016 at 19:32 Monty Taylor  wrote:
[...]

> [> The point here though, is that the versions of Python that OpenStack
> > has traditionally supported have been directly tied to what the Linux
> > distributions carry in their repositories (case in point, Python 2.6
> > was dropped from most things as soon as RHEL7 was available with Python
> > 2.7). With Go, there might need to be similar restrictions.
>
> Since this is a forward-facing thing, I think starting with the version
> that's in xenial is probably fine for today, yeah? That will be the
> version of go that will get installed in the gate starting with this cycle.
>

Apologies for commenting late on this thread - I needed to catchup with the
Go maintainer in Ubuntu (CC'ed) to get things straight from an Ubuntu
perspective.

a) Distribution of Go based projects in Ubuntu

tl;dr - we've been dealing with distribution of large Go projects in Ubuntu
for a number of years - so no problem if OpenStack wants to support Go as
an official language

Ubuntu supports at least three large Go codebases in archive as of Xenial -
Juju, LXD and Snappy are all written in Go, and as a result we've had a
focus on how to support them for end-users over the last few years.

As Monty points out, Golang 1.6 is the released version of Go in Xenial
(and its also installable for Trusty - "apt-get install golang-1.6-go");
that said the way the packaging has been done, its possible to introduce
newer golang versions without breaking the existing Go based packages in
the Ubuntu archive at any point in time;   The three Canonical projects in
archive are using 1.6 as a baseline for compatibility to make things a
little easier to manage; 1.6 will remain as the default Go version, but
newer versions may be introduced in parallel.

In terms of where code for dependencies of projects sits, Ubuntu has taken
a flexible stance on this - for components where version alignment is good
and there is good reason to want to identify the versions being used across
a number of packages, a separate golang-XXX package is produced - this
allows the Ubuntu Security team to monitor for CVE's, allowing for more
effective security support. A good example of this is the go.crypto
package.  For dependencies used by a single project, or where there is not
alignment with the packaged golang-XXX version, we're continuing to use the
version embedded by the consuming project.

The Debian toolchain around Go packages helps with managing this by adding
'Built-Using' fields to all Go binary packages that depend on separate
golang-XXX packages - which means that the archive keeps track of what was
used to produce a particular binary package.  This allows the distro to
easily analyse what needs rebuilding when a shared golang-XXX package is
fixed/updated in some way, as well as letting us deal with things like
transitions between Go versions (the golang package version is also
embedded in this data).

Shared library support is coming in Ubuntu (and Debian) for Go; however we
think its something that adds value to the distributor (avoiding rebuilds
for fully statically linked binaries) rather than the developer (esp in the
context of security management).  Oh and its still really new...

b) General technical feedback on Go development in the context of OpenStack

Note that I'm not a Go developer, but have been observing Go development
across a number of large Go codebases - these are things I've seen that
help both the development team and the distributors of their work.

i) Use godeps for dependency management

This is used across Juju, LXD and Snappy to manage dependencies at specific
commits/revisions and has proved invaluable.

ii) Don't embedded your dependencies in your VCS repository

Ideally when you cut a release artefact, bundle up the dependencies at this
point in time using godeps.

iii) Agree baseline versions

For each OpenStack release agree a baseline golang version, and common
version alignment on dependencies where appropriate.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack Liberty RC1 for Ubuntu 14.04 LTS and Ubuntu 15.10

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi All

The Ubuntu OpenStack Engineering team is pleased to announce the
general availability of the first release candidates for the OpenStack
Liberty release in Ubuntu 15.10 development and for Ubuntu 14.04 LTS
via the Ubuntu Cloud Archive.

Further release candidates will be pushed to the archives as and when
they appear.

Ubuntu 14.04 LTS
- 

You can enable the Ubuntu Cloud Archive for OpenStack Liberty on
Ubuntu 14.04 installations by running the following commands (make
sure you have an up-to-date software-properties-common package first):

  sudo add-apt-repository cloud-archive:liberty
  sudo apt-get update

The Ubuntu Cloud Archive for Liberty includes updates for Nova,
Glance, Keystone, Neutron, Cinder, Swift, Horizon, Ceilometer, Heat,
Designate, Barbican, Manila, Ironic, Trove and Sahara; Ceph (0.94.3),
RabbitMQ (3.5.4), QEMU (2.3), libvirt (1.2.16) and OpenvSwitch (2.4.0)
backports from Ubuntu 15.10 development have also been provided.

You can checkout the full list of packages and versions at [0].

Ubuntu 15.10 (Wily) development
- ---

No extra steps required; just start installing OpenStack!

Reporting bugs
- --

Any issues please report bugs using the 'ubuntu-bug' tool:

  sudo ubuntu-bug nova-conductor

this will ensure that bugs get logged in the right place in Launchpad
- - and come poke any of my team (zul, coreycb, gnuoy, thedac, ddellav
or beisner) in #ubuntu-server if something is particularly annoying or
broken…

Finally - thank you to everyone who’s made OpenStack Liberty RC1 a
reality - and have fun!

Cheers

James

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/liberty
_versions.html

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWDm1kAAoJEL/srsug59jDDO8QAIiv82Z7MiOdssAiN1jktbCE
6etKZE4mM2CqF91t1NYDNkjGbQvEYfFI1PpNrSd0HmLuybkMR0XEQj07oPhTgdJd
HUFvXwJBPzsPa2mBer5WylQz4RAuVBfdIanjvgAa4My/SvoLFDFjeSqXj0sYSBgC
VyGPdpk6c5NwkzaxsAYL7TB/BWGFzDWeht9YF4wNyvxzGQOhyMkxRvQ2VMRUMxHt
6z8iR+vSENoHzrV0UPt4wTG8L51ZkXv+TaC8pXZTEtSWTGjaOxEa0YMjX5I/bNwX
y3VkuOmoXn+6lshBNJrri8Mr/KtwrWAZ/+UnwT8GmwbPVQ49tdCd0hFC5LRBC7cR
fneEcGBcOxJ4ftzJP5HOz3ZnFH7szvSAfmPrdDCDvuN0bpCHuCbi6dPAjse3MqVp
LIKNWPSD1BEzPUONF4y+/9iIpEEPHt6ehxBu/i9i0fLt4/KYd51GuR+rl/ZvQjn4
G2tnTEuKn+2znT2D+Y2LyQgEZlIThewZJFUuTq5s+B3KhZ0orCuvRvY0qJMyHS0A
TA1XGxTEOp5DZVzVy0/rCyp5V316u//a4lSPHuP+1aneV2q7T3CkafjgNScG/P8h
wAg0clhe5vWeMMDlgooBEsOYak+AFObdtojpDTaVmtfEbUbwpRZ77/SnhWm7pBlA
M8C8gWQojDXLHD7Cox1s
=CPST
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi James

On 02/06/15 23:41, James E. Blair wrote:
> This came up at the TC meeting today, and I volunteered to provide
> an update from the discussion.

Thankyou - much appreciated.

> In general, I think there is a lot of support for a packaging
> effort in OpenStack.  The discussion here has been great; we need
> to answer a few questions, get some decisions written down, and
> make sure we have agreement.
> 
> Here's what we need to know:
> 
> 1) Is this one or more than one horizontal effort?
> 
> In other words, do we think the idea of having a single packaging 
> project/team with collaboration among distros is going to work?
> Or should we look at it more like the deployment projects where we
> have puppet and chef as top level OpenStack projects?

After some discussion with Thomas on IRC, I think this is more than
one effort; The skills and motivation for developers reviewing
proposed packaging changes needs to be aligned IMO - so I think it
makes sense to split the packaging teams between:

 Debian/Ubuntu + derivatives
 CentOS/Fedora/RHEL + derivatives

> Either way is fine, and regardless, we need to answer the next 
> questions:
> 
> 2) What's the collaboration plan?
> 
> How will different distros collaborate with each other, if at all?
> What things are important to standardize on, what aren't and how do
> we support them all.

For Debian/Ubuntu, Thomas and I are already working on re-aligning
packaging as much as possible for the Liberty cycle; to start off with
this will be the dependency chain, but we've also agreed to look at
the core openstack packages as well, which is where we have the
greatest delta today.

We will have to come up with some sort of smart way to continue to
manage that delta going forward - we've had quite black and white
opinions in the past as to what should be in the core packages and
what should not.  That said, we want to enable wider collaboration as
well.

By aligning branches for packaging against OpenStack releases, rather
than Debian or Ubuntu releases, I think we can gain the maximum
collaboration between Debian and Ubuntu, irrespective of which
OpenStack version is being shipped by each distro.

> 3) What are the plans for repositories and their contents?
> 
> What repos will be created, and what will be in them.  When will
> new ones be created, and is there any process around that.

I think Thomas has the definitive list of existing git repositories in
Debian that we can use for the majority of repos - but I'd like to
ensure we get the branches setup right on the openstack projects
themselves to represent the simpler Ubuntu base packaging and the more
complex Debian packaging.

Thomas and I can work on the details of that.

> 4) Who is on the team(s)?
> 
> Who is interested in the overall effort?  Who is signing up for 
> distro-specific work?  Who will be the initial PTL?

I'd like the members of my team who work on OpenStack packaging at
Canonical to be part of the Debian/Ubuntu development team; that would
include myself, Chuck Short and Corey Bryant.

As Thomas is already taking a lead and has control of the majority of
repository sources, I'd be happy for him to be the initial PTL;
however I would like to see the PTL role switch each cycle so as to
not overburden one individual, and to make sure that the team enjoys
the diversity of technical leadership and objectives of each distro.

> I think if the discussion here can answer those questions, you
> should update the governance repo change with that information, we
> can get alhat.l the participants to ack that, and the TC will be
> able to act.

Regards

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVbweuAAoJEL/srsug59jDRnEP/A6avj+hGBo46Y8H5K3LkEjn
YgUteWnHs0QsrOSO5zZBdx/xzAK+ADbrOL4hQ/8vGoBhzy3MhQIPXbWemrowE+CK
h3x71xYlSUzzxIuvLYmt+Gy9wsB/K5KEocB7hmgOL6lKRC1QyA0RF6RFEZ7HMbZ/
DydeeK0c4GW5mtrsZa708pVoWHsfcRpGUmX+80iXT4faREHQwTyscG/zb/xUaUhc
yBd47tIagcs28nuy7xOENiWwb++ydgbDtzg6OOWa48Eb1Jtskeh6cyiW4Yk8G8mS
OsOXZtRVpRpYAfu6dH8jg6k24I6oQBhPbqxz0bj4lI6eRvSPC+1fT8IvDHobisE/
rB2I51QXgBfeSFeOmZi2gP3lptXvA7cnY6z7L66BdVzooVbMJuLlUG50G4XXI4qt
XOhb8c+Gk0DpMtMq34HsBNN512TeCIqfWBbo+ZwKHHEGET/5GrWxuiFaGg9nPvQW
z/L88ew8pswulI64rxu7FKbokB245GNNutB6/nJY+YhqdrKR7ojROcXcgT1CYX6p
TzyuahaepW+M6N0Xs1Gh+YmacxnyJDFNZQyM7FoHiUc4+Wwp/DTmxBS4+aoVvedP
3nJ51ueBoXu5a5sSSxNfwWH+mvVtwpoKi5KYR8FWaAG0z0x7Wf0WEKtR+TM4ixXp
NNpLGulILZqefi6fyZ+w
=NuyQ
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thomas

On 03/06/15 16:23, Thomas Goirand wrote:
>>> This came up at the TC meeting today, and I volunteered to
>>> provide an update from the discussion.
> I've just read the IRC logs. And there's one thing I would like to
> make super clear.
> 
> We, ie: Debian & Ubuntu folks, are very much clear on what we want
> to achieve. The project has been maturing in our heads for like
> more than 2 years. We would like that ultimately, only a single set
> of packages Git repositories exist. We already worked on *some*
> convergence during the last years, but now we want a *full*
> alignment.

Actually I think we agreed to work towards alignment on the dependency
chain for OpenStack at the summit; alignment on the core packages
(bits of OpenStack you actually install) is going to be much more
challenging and might be something that we can't get full alignment on
between Ubuntu and Debian - so let's not jump the gun on having that
as a core objective for the packaging team.

As I've stated before, we will have to have some way of managing that
delta from the outset of moving any core packaging under the OpenStack
umbrella.

The Ubuntu packaging is used widely by end-users and a number of other
projects including the OpenStack Puppet and Chef modules as well as
the Juju charms for OpenStack - any changes to structure and behaviour
are going to have much wider impact and I'm keen to ensure that we
consider the requirements of our end users before we consider any full
convergence objectives.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVdVGyAAoJEL/srsug59jDs8YP/2dJJHaXpn++80fOGg3S2z3Q
0ifzNvgMQNPDGGLnfZ95Q/8iWXhqF03waNcd33MLI0+HKFtuBaTZ7P/W3ImDDpEE
B7TdwNGLzFN76Gz8Q9q0K+/6SxYGuwiWwlHrzJLaK4mEer83oojQ2v3Jxgw2SNx2
3UWamoFJm5o1s3Nh84QkpiXOQLZ51J1YjWXS0zz7gfqtgeiQvCr67l6dqJ/RaKGv
B1oWeV4nT+yAogWx/7VX5Vzywab5Vo1PmIRLAC6BX9mKEeqoFOAZC7bd+DUNNp/J
Rzg3KKQbSvXhL+xO0eByuWt4JE3EBJrI2bUz3LzutvWET5eJWnMY2gm1RmPcjguu
LFjNKF/Bmjgzk88kTF3k8kBgghhR0FKJyFfYi14j8RshgIh6ghtzfnHcyamsiaQe
8fitDq/k5p0u6F9zplJ2U4wYptV0COkwlcJTSOrvACQnziCOBM+k6VE2bcLqS5wC
kFnw/0I0iIycKFYxqvSBhR+fnWHQIXD9Swvh6EhF/VT6TQRKxIY2pOci/JYo+/Zv
rLTAfoKxmtlw8HOjifcLQSem7YoxF2O9qgUNqVkzg6g6PzpXAK4S8LnEq3on9v7p
wRJvFhmzfuo3xvtlsdvbTdea0VzRXCG0SM+XfEzB4FSvk4jhWI4TOuqiMxStq4SQ
QyZ3zzq0M0f5uEQ/xQZV
=zgNr
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/06/15 23:41, James E. Blair wrote:
> 3) What are the plans for repositories and their contents?
> 
> What repos will be created, and what will be in them.  When will
> new ones be created, and is there any process around that.

Having taken some time to think about this over the weekend, I'm keen
to ensure that any packaging repositories that move upstream are
packaging for OpenStack and other OpenStack umbrella projects.

Thomas - how many of the repositories under the pkg-openstack team in
Debian fall into this category - specifically projects under
/openstack or /stackforge namespaces?

I don't think we should be upstreaming packaging for the wider
OpenStack dependency chain - the Debian Python modules team is a much
larger team of interested contributors and better place for this sort
of work.

- -- 
James Page
Technical Architect
OpenStack Engineering Team
james.p...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVdVSwAAoJEL/srsug59jDGQ8P/jiupTb6Sx48QHAOkPSlJJBj
IFfLY/JLpV+lsdizaIEPH1S232qWg7JtPTVeRDYfEXGtRN+5whJD505frxmTesEN
W68LVMSybbIPIf8f++MMm6PZ1d0wq9STHf8Mi0PvzkjUcDO1xDASNzG2ZRh7X56C
bavfGXAxiYkIdzqB5lUTXoYhcKuMTFq0YzIIQv6Ebgst1hqeOCsEcXYvIEnOTVyM
Dgfc94h13+1+cSSwpo5ilcbwD2uAgsEDQBz2hFPShG7CigW6dY/454hXPCtDyWf7
alLgawiWYsQUmfjCz1ozVvzqrMoCFF1rFqlzlfXUTZc9obKDHtWzorO5KwTkkmRw
AIvnj/zYAlFBPDTDG84ZFVDAH9EJ2y5x3NiIoe16lLP67PGQiUO7BYJCoSQeZT2N
9axsihKmgdwm2icYBrmIFKS83aKUjAoYZ/TZd4yKYVqbdOtG2ysDAt7REXU63UZN
12KArxuFR8ygJS1Kl0MkRDOMX9omWJ8R5EgcEhjtbW6s0XBaaK38vCZECtCmnaBh
nEl+XHV/4GUxpNa424dvwWm8VAm+e0nIFycCBXqgpqdlpDGmAbLdX/B+Kygw5IEY
oI8WsEWbbHKBqdAuYU4ZUxHbUcYxzZ/mYwT9L5M/2ETOrOGsQRRJlxigUbgj4BVY
R/FemtQlWHCdbj3uDac3
=nMQI
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

nnaclient 
> python-swiftclient python-taskflow python-tempest-lib python-tooz 
> python-troveclient python-tuskarclient python-xstatic 
> python-xstatic-angular python-xstatic-angular-bootstrap 
> python-xstatic-angular-cookies python-xstatic-angular-lrdragndrop 
> python-xstatic-angular-mock python-xstatic-bootstrap-datepicker 
> python-xstatic-bootstrap-scss python-xstatic-d3 
> python-xstatic-font-awesome python-xstatic-hogan 
> python-xstatic-jasmine python-xstatic-jquery 
> python-xstatic-jquery-migrate python-xstatic-jquery-ui 
> python-xstatic-jquery.bootstrap.wizard 
> python-xstatic-jquery.quicksearch 
> python-xstatic-jquery.tablesorter python-xstatic-jsencrypt 
> python-xstatic-magic-search python-xstatic-qunit 
> python-xstatic-rickshaw python-xstatic-smart-table 
> python-xstatic-spin python-xstatic-term.js python-zaqarclient 
> stevedore

Again LGTM.

- -- 
James Page
Technical Architect
OpenStack Engineering Team
james.p...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVdqHJAAoJEL/srsug59jDFTkP/ibw9wOo4bah9nP539IUuIrw
3RNA+HGk5aT7htCetTsnNlTuKy7wM3EpG5ew2kHv4KMh6MiC7/wWZHfD0YBVXz8n
oXpYOOwJSZCEcSB374kNYux3nhOIP9Mqd8/dCmQ190fS7GduDdZY6Qk4RUnRFd3j
axB+UtZNaaLCcFCqJ3/7y57ovR/Tgqcn6Z+DM9uhuHTTEt2EdxKouOASjbjOqLgj
9WaqIiFmU6uQMZnVMnnI+R/OWixNp2b5scqT7P7GQSq7mrOk3nTmmpaQGmDiGyRN
ssDf1RzO/hdbT07OM+NOgxCbbsdf7xJnMsBXn2qibqNXoyGH0xTm6DQfREvULOUn
5vDDb5JzLauDc1Qb/dniIkg5su0jYZt6bSOQVPVvh+ddyV4+MQhdmjCrE0Aqh0Ph
dRA0qrqXmYTPIo/FCztV/Z7elQHISB3wTdURJtulfgOwaelnsZgGO3Dey0EmypQ2
TySbI1yeVJ7eS8fISduTqVw5oDq6P3OMcEoe2T+nownriKtvpS4SMZT6F1NdbDUO
28/BT08juJCJb8/rYwCYcU5JQ/0wX8BTlW2q/mNYBdHL50alsO/20yNg4roZ85+2
VsYynyTX1t8MTkd0XCIIhNjRu8enFZ2ofYZLbzPEVE8dYcyIedpMkXam1gqJZJid
EPIj63eWA6oCfSjnlKF1
=oH/P
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/06/15 15:12, Thomas Goirand wrote:
>> The initial core reviewers was seeded by representatives of
>> distro's and
>>> vendors to get their input on viability in distro's.
> Really? James, were you made core on the requirements?

Believe it or not, I've not *always* worked on OpenStack for Ubuntu
:-); that pre-dates my direct involvement.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVeEgKAAoJEL/srsug59jDrqEQAK6jXUCDzHb8XIVM6GM82QOy
+6NXp99us8xDzq/2mWuZAUZ4abon4JvZmOjngSoQmTXs1e9L3HiQr4iTlW4ZlJ9w
JCL8Xlq2/SJL8KJ2hMFg6sWanJZ0eglJ21F/bq2Rz6/fjhx/i7q8CPLHJghG5RXm
2sk9seXHFLK3syW4g/sVmz3MkPAYwu6ZqFiTDDcgNjkD+OegoMltn/d+HRLf20G9
VeTuL6mjW2ZnnJozBuqJ+ZbX+Gc35OhV8NWFzhaPkMPNT48BULr7rpfAgQ22WXyP
v9EnXaYtzyhUQBOdyrKXoPLK2dhCTcqRGImM1lZl3mKJbG/jf8d9U24M20bw4kQE
h6LHOyH+PQQcsAm+uKH2mpB8c+XElmeL7BO9sSUsC30oL0QI3OxRcFt/wgIycHwd
f8OoXPc8RsZERlsWYPF9gA16bTRQn08vIgVweNKu7vkP5qR6nvOjCzRBoUZdlIpu
4tqlzprYDSzSAJi8mzDq+nw3YulXjuTk/vQusp4MCjfA3VXS1yry8i+1HpjF/MO/
eAoKpZM2ntksRcObj947yh7ncsxjrQmOXHPfqMlbZTa6NWmQnElufJJ0nk5s30el
cBxUTjLN4lvAc6xjZPXqHk1U0kiP95E0wAa3EMVSDLeULG4Hq57+bSE63zHTts77
Y+UyyJswgeA6ZHC+W5Ct
=egET
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi All

On 27/05/15 09:14, Thomas Goirand wrote:
> tl;dr: - We'd like to push distribution packaging of OpenStack on
> upstream gerrit with reviews. - The intention is to better share
> the workload, and improve the overall QA for packaging *and*
> upstream. - The goal is *not* to publish packages upstream -
> There's an ongoing discussion about using stackforge or openstack. 
> This isn't, IMO, that important, what's important is to get
> started. - There's an ongoing discussion about using a distribution
> specific namespace, my own opinion here is that using
> /openstack-pkg-{deb,rpm} or /stackforge-pkg-{deb,rpm} would be the
> most convenient because of a number of technical reasons like the
> amount of Git repository. - Finally, let's not discuss for too long
> and let's do it!!!

While working to re-align the dependency chain for OpenStack between
Debian and Ubuntu 15.10, and in preparation for the first Liberty
milestone, my team and I have been reflecting  on the proposal to make
Ubuntu and Debian packaging of OpenStack a full OpenStack project.

We’ve come to the conclusion that for Debian and Ubuntu the best place
for us to collaborate on packaging is actually in the distributions,
as we do today, and not upstream in OpenStack.

Ubuntu has collaborated effectively with Debian since its inception
and has an effective set of tools to support the flow of packaging
(from Debian), bug reports and patches (to Debian) that have proven
effective, in terms of both efficiency and value, ever since I’ve been
working across both distributions.

This process allows each distribution to maintain its own direction,
whilst ensuring that any value that might be derived from
collaboration is supported with as minimal overhead as possible.

We understand and have communicated from the start of this
conversation that we will need to be able to maintain deltas between
Debian and Ubuntu - for both technical reasons, in the way the
distributions work (think Ubuntu main vs universe), as well as
objectives that each distribution has in terms of the way packaging
should work.

We don’t think that’s going to be made any easier by moving all of the
packaging under the OpenStack project - it just feels like we’re
trying to push a solved problem somewhere else, and then re-solve it
in a whole new set of ways.

The problem of managing delta and allowing a good level of
distribution independence is still going to continue to exist and will
be more difficult to manage due to the tighter coupling of development
process and teams than we have today.

On this basis, we're -1 on taking this proposal forward.

That said, we do appreciate that the Ubuntu packaging for OpenStack is
not as accessible as it might be using Bazaar as a VCS. In order to
provide a more familiar experience to developers and operators looking
to contribute to the wider Openstack ecosystem we will be moving our
OpenStack packaging branches over to the new Git support in Launchpad
in the next few weeks.

Regards

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVfudNAAoJEL/srsug59jD2isQAKtp9gSQ7FC0dy664wkSIqp3
ztmtIGPu5k0kZsg0sSxie3lA6mmRtv0m3sZWweNXfObXKwrWSgJSNynYDOhhiC7u
zlijQwEoY264byd7I+qacCdGBPi8fkXImB+6yx6OdJuHO+DcF/lBhF/5XW+wEwMa
j5GLN/UML+AO/Vp1BNBWholdCy/vm8SYDWtD3952R3fasBusCzpGj/52Pe3JifV6
kYWhnoihSQn+U02SXUc4/JETl/3o94EKp5/eu9We49sEdgHudSF3o6MdyLom2NfM
BNMpWs4iNWz7BlgqoDULotrFORRjQawru9R5StouB+wORUJrgVG+5lFINiR4RA+h
EMGXAshda+xwqm3KrdtHDLHRgFyfYov6w7s+caUMyV7gky1zmrB/NR+vG8Di2U2/
wyK+4y/c/Qt1CFhZSmuZ0zqzRzX7J2oxlT4P9FVdapnL5AYfXe6hZWhHJERjXmeS
GPovCQO/tBqRUiL9RwX6rcYbxykh9oseP4yxp5QZwLIO7cuIaStgMIN8z1vpZoBf
r7l3Bbd+ppRcq8NDqa7elRP0uiHm0wg7gMMcMWJJOJMU2Jm5DAw7PvZSA2FbksDL
Cu8WAloTsFCg11at6oTz6IcxdXsXTkpNp8O8Qv2yICj3Kw7gwX22Mc4V/CclrtFp
8lKFkTacJVbMkihgOFpu
=QN+b
-END PGP SIGNATURE-

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

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Thomas

On 15/06/15 19:48, Thomas Goirand wrote:
[...]
> During our discussions at the Summit, you seemed to be
> enthusiastic about pushing our packaging to Stackforge. Then others
> told me to "push it to the /openstack namespace" to make it "more
> big tent-ish", which made me very excited about the idea.

The idea of having packaging on stackforge seemed appealing; however
its always good to reflect on these things after some thought away
from the summit, hence my email yesterday.

> So far, I've been very happy of the reboot of our collaboration,
> and felt like it was just awesome new atmosphere. So I have to
> admit I'm a bit disappointed to read the above, even though I do
> understand the reasoning.

Ditto on the reboot of collaboration - I think we've made good steps
forward in the last two weeks to work together in the right ways
between Ubuntu and Debian.  We've still some way to go :-).

> Anyway, does this mean that you don't want to push packaging to 
> /stackforge either, which was the idea we shared at the summit?

Yes.

> I'm a bit lost on what I should do now, as what was exciting was 
> enabling operation people to contribute. I'll think about it and
> see what to do next.

Lets focus on the seed of collaboration we have going right now and
see how that plays out.

Cheers

James

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVgAARAAoJEL/srsug59jDtfgQAJgTXuoOKiXGt6HbcGP+VpeM
o1SUq8EAg70rpgxtz97wqdW5rZ8u7PRVepx24kFdGSnzvoFMU9Sb3wgM/osjxaig
+u2gELObxAKDzKQM/sYWxuIiMNEXwkYWo/PP/hS8WUfsImtmW991ZoQAseD9Yw+k
5D53UxnLbMxdv7Q2qMLEICQwOK6drEQu1Z7GG/X47plwsgVPbHjZ3apsOpbA41zA
8XniBVyAfSurS3vDqCwBk16YcYhsFPn9OjZZ9TDbWTsIuRr6/zBWObWTwwBPqFGv
+ks45fhIfLHQJo/BN7MclDQE2Tk7Fc5fTdVme6jUBY8RbIfAw3T8S+LdmtQGL6eP
ug7CcDi0aeUIm0s1Z1Cb7HKicoaBrkqPwpIs5TYkAETFiBuh6/qbCDXxPHyR+8/F
/r2jFCZmzdyPw2GW/vTkripQb2YmvsvdjkY5tBXQEaFa6bp804Li3wIBXY0DDkzw
plFXKAUpyGip/Oj14aHNM7gZZ5dGAjjAJMBLpKcHYoM/B7grup2/ySI/b9w/v3Pj
NuKZzEhfEC6W7tuBmJ0F3LyoBTz0uBtY0ar3xIO9yU87v7jz33N+2w6Sei9qaBkh
6Fsh0NpHc5u1NLQ3I+8c3jgRXBTl1+xOPDXZokFnaoM8sl4VdTUx7kp6yD1nrpLO
z4tsCjcPXAcLVtxsyW/y
=++l/
-END PGP SIGNATURE-

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

Re: [openstack-dev] Debian already using Python 3.5: please gate on that

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/06/15 21:44, Jeremy Stanley wrote:
>> Based on that, I am confident in sticking with our plan of gating
>> using
>>> 3.4 for now and keeping an eye on the 3.5 packages being built
>>> by Debian and Canonical.
> Unless we shift platforms and go back to special-casing Py3K jobs,
> I expect to see us testing the N release cycle on Python 3.5 in
> Ubuntu 16.04 LTS but probably not prior unless someone steps up to
> make it happen differently.

That sounds reasonable to me; I spoke with the Python maintainers in
our Foundations teams (one of whom also maintains Python in Debian)
and the expectation is that they will start doing working this cycle
(15.10) but I think its realistic that 16.04 would be the target for a
default python 3 switch.

As Thomas points out, we have 3.5 in Debian experimental and Ubuntu
Wily; at some point in time, Debian/Ubuntu will start doing rebuild
testing with these newer versions - we'll feed any bugs/fixes back
upstream so hopefully when we get to the 16.04/3.5 testing enablement,
it will all *just work*.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVhBq5AAoJEL/srsug59jDnQ8P/RMbWz2goTHrWZA/+yzpwtPG
GucjSbG8YIPfJFWiAnyOaW3eh+XMrisFvS2QFn+7VBPhrJYZiiTBXAU8rAGZ7sgS
q2EGmgzkFXLt/Zsw6ej/3E7cZFTqDOB8mT/9cqvxjsLSZ9ulaOEh02BUJJz+Idez
FwEUY9Y0mYmzMLgGQpvDGGox9JlnwzhS4EbSKIafE4+8fzscnyWbVYvnpCXm4Rkb
jVupr4isdvdOK/oKog/1CgnjU1WFkBIJxMSl2X7aoSt9gAp4u+6sAVdON50hL6JQ
/TEbJIHahtSskmvzw0HMhdYr3XrkVf92RvqGXsbH2Ce/UoMCocqxqedQ8sp0R98u
inICxqCoEdjQYMFUJ8QsaYQXaMuQNkKdKYzTPInNCFKxsIqyuDSzJAEe/EyfgRuD
Yyt76eEbRoFBtVGCcMbEGby/AAbkMWdRx7hmFpHDLh7VKbTTDwtB83+3qppx5Mia
Tz1MTxtd9ggAf/PDRJmbr3y51FXbx4J8e4DNJXI3DNG7Lqakmhx7c8lf7n2tyfBb
EBckPcGGEGc5cisVLBdrmVlREVNVM2gTb9Z5Is/Lqgm0n336/fTOmFcduA/litBK
EbyYERjhCPuCHPCEF/jYVCzTREJM/S/2Vm5hraVjDaMYqu6O9gysze2pkTuP4L51
Ew8I7sRfTKrLdZFzeU/x
=8N/+
-END PGP SIGNATURE-

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

[openstack-dev] [puppet] [ansible] [docs] Packaging changes about to land for Ubuntu + Neutron/Mitaka

[James Page]

Hi Folks

We're about to push the next set of updates into the mitaka-proposed area
of the Ubuntu Cloud Archive; these include changes to three neutron agent
packages which will have impact on end-users and documentation as well as
puppet modules, ansible playbooks, chef cookbooks etc...

1) Package renames

neutron-plugin-openvswitch-agent -> neutron-openvswitch-agent
neutron-plugin-linuxbridge-agent -> neutron-linuxbridge-agent
neutron-plugin-sriov-agent -> neutron-sriov-agent

Transitional packages are included for upgrades (so the old package names
will still work), but the name of each service no longer includes '-plugin'.

https://bugs.launchpad.net/bugs/1548244
https://bugs.launchpad.net/bugs/1321257

2) Dropping of ml2_conf.ini on config-file path for agents

Last cycle we included both the ml2_conf.ini and associate agent ini file
for each daemon as startup arguments to help upgraders deal with the
transition to agent ini files; ml2_conf.ini has now been dropped.

https://bugs.launchpad.net/bugs/1527005

Regards

James
__
OpenStack Development Mailing 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] Mitaka, Xenial, OVS Firewall Driver, DPDK, VXLAN and Provider Networks

[James Page]

Hi Thiago
On Sat, 27 Feb 2016 at 23:58 Martinx - ジェームズ 
wrote:
[...]

However, I am curious about the following scenarios:
>
>  Will be possible to use, at the same time (same Network and Compute nodes
> / Host Aggregate):
>
>  1- Regular OVS bridges without DPDK for VXLAN Networks, with
> OVS-Firewall-Driver and;
>
>  2- OVS powered by DPDK for Provider Networks only ( without any firewall,
> current case anyway, due to
> https://bugs.launchpad.net/neutron/+bug/1531205).
>
> ?
>
>  I have NFV Instances that are also, DPDK L2 Bridges running on KVM Guest
> / VirtIO, that are physically wired using Provider Networks (flat and
> vlans).
>
>  So, for the Instance's vNICs (eth1 and eth2) that are used as a L2
> bridge, I don't want any kind of ovs-firewall (I'm not affected by LP
> #1531205 on this case) and I want OVS+DPDK under it but, for SSH into the
> Instance to manage it (via its eth0), it is still using regular VXLAN with
> Security Groups - OVS-Firewall from now on (no need for DPDK under eth0 /
> VXLAN).
>
>  I'm curious about this specially because the OVS Ubuntu package, makes
> use of Debian's Alternatives subsystem, and we need to choose one OVS
> (default), or another (with DPDK), via "update-alternatives", so, will be
> possible to select OVS with DPDK but, use regular bridges with it as well
> (for VXLAN networks)?
>

We're shipping two binaries due to the baseline CPU requirement for DPDK
being above the general baseline in Ubuntu; the DPDK enabled binary
supports all of the things that the vanilla binary does + DPDK.


>  If yes, how to create a VXLAN network with regular OVS and another
> FLAT/VLAN network with OVS+DPDK ?
>

Not sure whether a mixed mode openvswitch deployment is possible on a
single compute node - I can see how to switch between netdev and system
based bridges in the agent configuration, but that applies at the agent
level, not to specific bridges.

Cheers

James
__
OpenStack Development Mailing 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] Use of egg snapshots of neutron code in neutron-*aas projects/distributing openstack

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Folks

The split-out drivers for vpn/fw/lb as-a-service all make use of a
generated egg of the neutron git repository as part of their unit test
suite dependencies.

This presents a bit of a challenge for us downstream in distributions,
as we can't really pull in a full source egg of neutron from
git.openstack.org; we have the code base for neutron core available
(python-neutron), but that does not appear to be enough (see [0]).

I would appreciate if dev's working in this area could a) review the
bug and the problems we are seeing a b) think about how this can work
for distributions - I'm happy to create a new 'neutron-testing' type
package from the neutron codebase to support this stuff, but right now
I'm a bit unclear on exactly what its needs to contain!

Cheers

James


[0] https://bugs.launchpad.net/neutron/+bug/1422376

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJU4gj5AAoJEL/srsug59jD5agP/1NFgrLQjD7+d0OrxSByD+b0
DEwlbSwFGvV6sIbjzP8/9ibUmxnCOcwW9Enn4+Ukp4KuhuWKuiEZYdOARkuEupaz
IyDw3F9NzytnER2s+sn2+tddQloTjCk0vzk+e5uH19ovwoLBmFOd/g5d+yNYt/SB
ozzA3S4WTyG8vws2AOBcubJkg1wYzyUSGATceBqYLFMa7e7GuazRR/XohOwa7iux
T1+4t72juhXUiFiPn4GD2aWjl30Eer0+juHdlje6EHtSRnODJXnYeEHIw/ndmTCy
gEmMZ3c9fUoJC51HBeOSjX+Mg5Hq/AaGLLQHU+shklg6pgXKZ1ZKFAYD5rjWrXB2
jxPM0vFcJEh2yfMHTsgbgP6AnYF5g7/36izTdJsXWDgEJoE7Zt2J+NX5+SLTihtt
GbWIUh5ZstZXBD85u4o8iB+whhpzZd7rE/GRK2Ax/kY8WnB8xeiU5wA5AQN6nTMr
XPT/ObXsXKnyrLgn4KkRZymEeDO1yaaVrtGtLxF2Dap2CpH8so7hLQw/3KYxDsTP
8dptOS4EzVm+jZPdAHMHIqsyA2wnRfyauPAyYDEeVioCUkijinrt61x62OM5s8+X
MbAOyjGGOPVXq0tFChbB9ZdSkMDNvj98sv1xhZ1yHmoKvJ56EM1drh7HhcJWD6/v
dv9uUmY4DhVlvjYKwPgY
=C4vr
-END PGP SIGNATURE-

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

[openstack-dev] [charms] 17.02 OpenStack Charms release

[James Page]

Hi All

I'm pleased to announce the 17.02 release of the OpenStack Charms.

In addition to 120 bug fixes across the charms and support for the Ocata
OpenStack release, there are new charms for Ceph FS and Manila and to
support integration of Keystone with LDAP/Active Directory leveraging
domain specific drivers with Keystone v3 domains.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/developer/charm-guide/1702.html

It's also worth noting that bug reporting has now been moved out of the
Juju Charms distribution on Launchpad into individual projects for each
charm under the OpenStack Charms project group:

  https://launchpad.net/openstack-charms

All existing bugs have been migrated to the new project locations.

Thanks go to the following contributors for this release:

  Seyeong Kim
  Mario Splivalo
  Ante Karamatić
  Shane Peters
  JuanJo Ciarlante
  Billy Olsen
  Paolo de Rosa
  Frode Nordahl
  Felipe Reyes
  David Ames
  Liam Young
  Edward Hope-Morley
  Chris MacNaughton
  Chris Holcombe
  Alex Kavanagh
  Brad Marshall
  Dmitrii Shcherbakov
  Ryan Beisner
  Viswesuwara Nathan
  Pascal Mazon
  Hua Zhang
  Chris Glass

Cheers

James
__
OpenStack Development Mailing 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] [charms] bug day this thursday (2nd March)

[James Page]

Hi All

Just a reminder that we'll be running our regular bug day on the 2nd March
(this coming thursday).

Focus, as always, is to touch new bugs and work through in priority order
for any fixes!

Please co-ordinate any activity in the #openstack-charms channel!

Cheers

James
__
OpenStack Development Mailing 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] [ptls] Project On-Boarding Rooms

[James Page]

Hi Kendall

On Wed, 15 Mar 2017 at 18:22, Kendall Nelson  wrote:

> Hello All!
>
> As you may have seen in a previous thread [1] the Forum will offer project
> on-boarding rooms! This idea is that these rooms will provide a place for
> new contributors to a given project to find out more about the project,
> people, and code base. The slots will be spread out throughout the whole
> Summit and will be 90 min long.
>
> We have a very limited slots available for interested projects so it will
> be a first come first served process. Let me know if you are interested and
> I will reserve a slot for you if there are spots left.
>

Charms project would like a slot if possible please!

Cheers

James
__
OpenStack Development Mailing 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] [snaps] proposing Dmitrii Shcherbakov for core review team

[James Page]

Hi Snappers

Dmitrii did some good work on the ceilometer snap and has been providing
reviews and feedback of other changes in the queue over the last few months
as well has hanging out and being a sounding board/answering questions in
#openstack-snaps.

He's also working out how to get libvirt functional in a snap (no mean
feat).

I'd like to propose Dmitrii to the snaps core reviewers team.

Cheers

James
__
OpenStack Development Mailing 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] [snaps] proposing Dmitrii Shcherbakov for core review team

[James Page]

On Wed, 22 Mar 2017 at 15:10 Corey Bryant 
wrote:
[...]

> +1
>
> I have full confidence in Dmitrii.  He's already a great asset to snaps
> and will be great to have as a core reviewer.
>

And then there were three...

welcome to the core reviewers team Dmitrii!

Cheers

James
__
OpenStack Development Mailing 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] Switching gate testing to use Ubuntu Cloud Archive

[James Page]

On Tue, 4 Apr 2017 at 14:38 Daniel P. Berrange  wrote:

> On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> > Hello,
> >
> > One of the major sets of issues currently affecting gate testing is
> > Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> > and they happen frequently [0][1][2]. These issues appear to only affect
> > Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> > #openstack-nova it is clear that Libvirt isn't interested in debugging
> > such an old version of Libvirt (1.3.1). And while it isn't entirely
> > clear to me which exact version would be acceptable to them the Ubuntu
> > Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>
> If going to the libvirt upstream community for help, we'd generally want
> to see the latest upstream release being used. Ideally along with
> willingness
> to test git master if investigating a troublesome issue, but we understand
> using git master is not practical for many people.
>
> If using an old version provided by an OS distro, then we would generally
> expect the OS distro maintainers to lead the investigation, and take the
> responsibility for reproducing on latest upstream. Upstream libvirt simply
> doesn't have bandwidth to do the OS distro maintainers job for them when
> using old distro versions.
>

Agree on the responsibility for maintenance of libvirt in Ubuntu. Christian
Ehrhardt (cpaelzer) has been working to help resolve the libvirt 1.3.1 bugs
currently impacting the gate and does have updated packages available for
testing, but right now we're not able to reproduce the bugs outside of the
gate environment so verifying that these actually resolve the underlying
issues is proving problematic.
__
OpenStack Development Mailing 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] Switching gate testing to use Ubuntu Cloud Archive

[James Page]

Hi Clark

On Tue, 4 Apr 2017 at 00:08 Clark Boylan  wrote:

> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>

tl;dr - Christian (cpaelzer) is working towards resolution of the libvirt
1.3.1 issues in Xenial, but right now we're stuck on reproduction of the
issues outside of the gate.


> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
>
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
>

+1 on taking this approach - this also aligned with what we deploy and test
with for the OpenStack Charms.

Please stick to using the updates pockets from the Ubuntu Cloud Archive
(which I can see in the review referenced that you are doing); all UCA
testing of packaging and version updates is done in the proposed pockets so
this should ensure a better level of stability for the OpenStack gate.

[...]

> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.


Worth noting that in the same way that we update OpenStack packages in the
UCA for new minor and patch releases, we also do the same for Open vSwitch
patch releases - so the Ocata UCA will get released Open vSwitch versions
on the 2.6.x series.

The Pike UCA will (probably) get a newer version of Ceph which might be of
interest for gate testing as well.

Cheers

James
__
OpenStack Development Mailing 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] [networking-bagpipe] exabgp dependency

[James Page]

Hi

I'm working on the wider networking-* packages we have in Ubuntu for Pike
milestone 1 and noticed that exabgp is currently being pulled in from the
master branch of exabgp; any ideas when you might be able to switch to a
released version of exabgp?

Cheers

James
__
OpenStack Development Mailing 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] [networking-bagpipe] exabgp dependency

[James Page]

Hi Thomas

On Thu, 27 Apr 2017 at 17:03  wrote:

> Indeed, we have moved from shipping a fork of an old exabgp in bagpipe-bgp
> (a.k.a."vendoring", i.e. baaad...) to using upstream, but we have
> dependencies on exabgp development branch.
>
> I've been in touch with ExaBGP main author, who plans to release exabgp 4
> from master "soon".
> The one pending item he would like to cover before releasing is having
> exabgp run with python3, and not everything is ready [1].
>
> So, while I don't have a full answer on the "when", this is reasonable
> information on the "how" this will happen.
> I hope this can be achieved in a timeframe compatible with Pike, and plan
> to spend some time helping this happen.
>
> Once this is done, we'll also work to include exabgp in
> global-requirements.
>

That all sounds great; I'll hold off on the first milestone for this
package in Ubuntu for now and we can review again at the next milestone!

Cheers

James
__
OpenStack Development Mailing 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] [charms] Onboarding session at next weeks summit

[James Page]

Hi All

The OpenStack summit is nearly upon us and for this summit we're running a
project onboarding session on Monday at 4.40pm in MR-105 (see [0] for full
details) for anyone who wants to get started either using the OpenStack
Charms or contributing to the development of the Charms,

The majority of the core development team will be present so its a great
opportunity to learn more about our project from a use and development
perspective!

I've created an etherpad at [1] so if you're intending on coming along,
please put your name down with some details on what you would like to get
out of the session.

Cheers

James

[0] http://tiny.cc/onhwky
[1] https://etherpad.openstack.org/p/BOS-forum-charms-onboarding
__
OpenStack Development Mailing 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] [charms] Bug Day Thursday 4th May

[James Page]

Hi Team

Just a quick reminder that this Thursday is charm bug day!

Please focus on triage and resolution of bugs across the openstack charms -
the new bugs URL is in the topic in #openstack-charms on Freenode IRC.

Happy bug hunting!

Cheers

James
__
OpenStack Development Mailing 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] [networking-bagpipe] exabgp dependency

[James Page]

Hi Thomas

On Tue, 23 May 2017 at 09:14  wrote:

> Hi James,
>
> FYI, exabgp 4.0.0 has been released and this release can be package to
> satisfy networking-bagpipe needs.
> A request for adding exabgp as a proper OpenStack requirement is in
> flight: https://review.openstack.org/#/c/467068
>

Great - added to my TODO list for pike b2.

Cheers

James
__
OpenStack Development Mailing 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] [infra] openstack-ubuntu-testing-bot -- please turn off

[James Page]

Hi Ian

On Fri, 9 Jun 2017 at 07:57 Ian Wienand  wrote:

> Hi,
>
> If you know of someone in control of whatever is trying to use this
> account, running on 91.189.91.27 (a canonical IP), can you please turn
> it off.  It's in a tight loop failing to connect to gerrit, which
> probably isn't good for either end :)


Disabled - apologies for any issues caused.
__
OpenStack Development Mailing 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] Required Ceph rbd image features

[James Page]

On Wed, 21 Jun 2017 at 20:08 Jason Dillaman  wrote:

> On Wed, Jun 21, 2017 at 12:32 PM, Jon Bernard  wrote:
> > I suspect you'd want to enable layering at minimum.
>
> I'd agree that layering is probably the most you'd want to enable for
> krbd-use cases as of today. The v4.9 kernel added support for
> exclusive-lock, but that probably doesn't provide much additional
> benefit at this point. The striping v2 feature is still not supported
> by krbd for non-basic stripe count/unit settings.
>

The newer cinder ceph replication features use journaling and exclusive-lock
(see [0]), so any krbd based driver would not be able to support this
feature right now.

[0]
http://ceph.com/planet/openstack-cinder-configure-replication-api-with-ceph/
__
OpenStack Development Mailing 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] [nova-lxd] Broken nova-lxd

[James Page]

Morning

On Thu, 27 Jul 2017 at 23:58 Michael Still  wrote:

> Hi,
>
> I'm cc'ing openstack-dev because your email is the same as the comment you
> made on the relevant review, and I think getting visibility with the wider
> Nova team is a good idea.
>
> Unfortunately this is a risk of having an out of tree Nova driver, which
> has never been the recommended path for implementing drivers for Nova.
> Being out of tree isn't forbidden, but it does come with the cost of
> staying up to date with Nova and handling changes as they occur.
>

Agreed - and we've felt this from time-to-time since the nova-lxd driver
was started.

Maybe the Queens cycle might be a good time to review our out-of-tree-ness
and see whether the Nova team would be prepared to accept the LXD driver
in-tree.

I'm more comfortable now with where we are with regards to devstack tempest
testing in the gate for the LXD driver, although we do still have some
feature gaps compared to the libvirt driver (specifically boot from volume)
which results in a large-ish skip list.


> In this case, if you look at the review chain you'll see that the move is
> a pre-cursor to moving this code to use oslo.privsep. Unless lxd is going
> to move to privsep in lockstep with nova, your best bet would be to
> duplicate this utility method in the nova-lxd codebase.
>

We'll duplicate right now (see [0]) to unblock the current problem and take
a look at the work to move lockstep with nova to use oslo.privsep.

Cheers

James

[0] https://review.openstack.org/#/c/488254/
__
OpenStack Development Mailing 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] [charms] ptl for queens

[James Page]

Hi All

I would like to announce my candidacy for PTL of the OpenStack Charms
project
for the Queens development cycle.

We've made some good progress during the Pike cycle in terms of improving
documentation, with a new deployment guide in the works which should make
things
much easier for new users of the OpenStack Charms going forwards; There is
still
work todo here and that's something I want to make sure we focus on during
the
next development cycle.

We also have a number of cleanups that need to be completed; ZeroMQ and
PostgreSQL
support in the charms are obsolete and not covered by any testing so should
be
dropped during Queens.  We also need to make the jump to Python 3 by default
across all charms.

I look forward to steering the helm for another cycle!

Cheers

James
__
OpenStack Development Mailing 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] [charms][ptg] PTG planning pad

[James Page]

Hi All

I've started a planning etherpad for the PTG next month; feel free to add
topics you want to discuss/sprint on during the week.

  https://etherpad.openstack.org/p/ptg-queens-charms

Cheers

James
__
OpenStack Development Mailing 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] [charms] PTL cover for the next two weeks

[James Page]

Hi All

As I'm off in the backwaters of Scotland with zero chance of any internet
access for the next two weeks, I'm delegating my PTL responsibilities to
the capable Ryan Beisner until my return.

I'll be back just after the charms final freeze in the leadup to the charms
release at the start of September.

Have fun

James
__
OpenStack Development Mailing 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] [charms] Openstack with OVN

[James Page]

Hi Aakash

On Tue, 29 Aug 2017 at 05:09 Aakash Kt  wrote:

> Hello all,
> Resending this mail since I think there might have been some error
> sending it the last time.
>
>I am looking to develop an openstack bundle which uses OVN as the SDN.
> I have been reading : https://docs.openstack.org/charm-guide/latest/
> I have also read :
> https://docs.openstack.org/networking-ovn/latest/install/index.html
>

Awesome; we chatted about this on IRC a few times but put off any concrete
work until OVN 2.8.0 is released (soon).

As far as I understand, this will require me to replace the
> "neutron-openvswitch" charm in the openstack base bundle. However, I am not
> able to exactly understand what all I will have to rewrite / replace to
> make this work.
>

I think the new charm work is actually three charms (or maybe two) -
neutron-ovn (replacing neutron-openvswitch alongside nova-compute
deployments), neutron-api-ovn (providing the API only integration of the
Neutron API to OVN), and probably an ovn charm for deployment of OVN
itself, with relations  <->  <->  for
propagation of configuration in deployments.  The ODL charm set is similar
is high level design (neutron-api-odl, odl-controller, openvswitch-odl).


> Specifically, I need to make neutron work only as an API instead of the
> full blown SDN. Also, in the above doc, its mentioned that we have to run
> some setup on "controller nodes". How does the term "controller node" map
> to the charm?
>

Controller nodes are one option for the charms, however components of the
controller nodes are deployed inside LXD containers to provide separation
between services.  For example, you can dedicated three physical servers
and then deploy the nova-cloud-controller, neutron-api, glance, keystone,
cinder, ceilometer, heat etc.. charms in LXD containers onto those physical
machines.  So in the case of OVN, we'd look to deploy the ovn charm on
these same physical servers.

Hope that helps explain things a bit; if you want to drop into
#openstack-charms to ask more questions please do, or you can join one of
our weekly meetings and we can discuss further.  We'd normally start a
piece of work like this with a spec (
http://specs.openstack.org/openstack/charm-specs/); this topic is something
we could discuss in a bit more detail at the PTG in Denver (I'll add an
item to the agenda for the charms room).

Cheers

James
__
OpenStack Development Mailing 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] [charms] IRC meeting 11th September cancelled

[James Page]

Hi Team

I'm cancelling next Mondays IRC; we're (mostly) meeting for the PTG anyway
and can re-sync the following Monday.

Cheers

James
__
OpenStack Development Mailing 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] [charms] PTG summary

[James Page]

Hi All

Here’s a summary of the charm related discussion from PTG last week.

# Cross Project Discussions

## Skip Level Upgrades

This topic was discussed at the start of the week, in the context of
supporting upgrades across multiple OpenStack releases for operators.  What
was immediately evident was this was really a discussion around
‘fast-forward’ upgrades, rather than actually skipping any specific
OpenStack series as part of a cloud upgrade.  Deployments would still need
to step through each OpenStack release series in turn, so the discussion
centred around how to make this much easier for operators and deployment
tools to consume than it has been to-date.

There was general agreement on the principles that all steps required to
update a service between series should be supported whilst the service is
offline – i.e. all database migrations can be completed without the
services actually running;  This would allow multiple upgrade steps to be
completed without having to start services up on interim steps. Note that a
lot of projects all ready support this approach, but its never been agreed
as a general policy as part of the ‘supports-upgrade‘ tag which was one of
the actions resulting from this discussion.

In the context of the OpenStack Charms, we already follow something along
these lines for minimising the amount of service disruption in the control
plane during OpenStack upgrades; with implementation of this approach
across all projects, we can avoid having to start up services on each
series step as we do today, further optimising the upgrade process
delivered by the charms for services that don’t support rolling upgrades.

## Policy in Code

Most services in OpenStack rely on a policy.{json,yaml} file to define the
policy for role based access into API endpoints – for example, what
operations require admin level permissions for the cloud. Moving all policy
default definitions to code rather than in a configuration file is a goal
for the Queens development cycle.

This approach will make adapting policies as part of an OpenStack Charm
based deployment much easier, as we only have to manage the delta on top of
the defaults, rather than having to manage the entire policy file for each
OpenStack release.  Notably Nova and Keystone have already moved to this
approach during previous development cycles.

## Deployment (SIG)

During the first two days, some cross deployment tool discussions where
held for a variety of topics; of specific interest for the OpenStack Charms
was the discussion around health/status middleware for projects so that the
general health of a service can be assessed via its API – this would cover
in-depth checks such as access to database and messaging resources, as well
as access to other services that the checked service might depend on – for
example, can Nova access Keystone’s API for authentication of tokens etc.
There was general agreement that this was a good idea, and it will be
proposed as a community goal for the OpenStack project.

# OpenStack Charms Devroom

## Keystone: v3 API as default

The OpenStack Charms have optionally supported Keystone v3 for some time;
The Keystone v2 API is officially deprecated, so we had discussion around
approach for switching the default API deployed by the charms going
forwards; in summary

New deployments should default to the v3 API and associated policy
definitions
Existing deployments that get upgraded to newer charm releases should not
switch automatically to v3, limiting the impact of services built around v2
based deployments already in production.
The charms already support switching from v2 to v3, so v2 deployments can
upgrade as and when they are ready todo so.
At some point in time, we’ll have to automatically switch v2 deployments to
v3 on OpenStack series upgrade, but that does not have to happen yet.

## Keystone: Fernet Token support

The charms currently only support UUID based tokens (since PKI was dropped
from Keystone); The preferred format is now Fernet so we should implement
this in the charms – we should be able to leverage the existing PKI key
management code to an extent to support Fernet tokens.

## Stable Branch Life-cycles

Currently the OpenStack Charms team actively maintains two branches – the
current development focus in the master branch, and the most recent stable
branch – which right now is stable/17.08.  At the point of the next
release, the stable/17.08 branch is no longer maintained, being superseded
by the new stable/XX.XX branch.  This is reflected in the promulgated
charms in the Juju charm store as well.  Older versions of charms remain
consumable (albeit there appears to be some trimming of older revisions
which needs investigating). If a bug is discovered in a charm version from
a inactive stable branch, the only course of action is to upgrade the the
latest stable version for fixes, which may also include new features and
behavioural changes.

There are some technical challenges with regard 

[openstack-dev] [charms] bug day this Thursday

[James Page]

Hi All

Reminder that as this Thursday is the first Thursday of the month its
officially a bug triage/fix day!

Our new (23) queue is looking better than ever [0] so it would be great to
get that down to near 0.

After that focus should switch to High (62) and then Medium (174) bugs
already Triaged.

Please coordinate any activity in #openstack-charms so we don't all end up
triaging the same stuff; if you're working on a bug please make sure to
assign it to yourself and mark is as 'In Progress'.

Cheers

James

[0]
https://bugs.launchpad.net/openstack-charms/+bugs?search=Search&field.status=New&orderby=-importance
__
OpenStack Development Mailing 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] [packaging][all] Sample Config Files in setup.cfg

[James Page]

On Tue, 3 Oct 2017 at 18:15 Doug Hellmann  wrote:

> Excerpts from Jesse Pretorius's message of 2017-10-03 15:57:17 +:
> > On 10/3/17, 3:01 PM, "Doug Hellmann"  wrote:
> >
> > >> Given that this topic has gone through several cycles of discussion
> and has never gone anywhere, does it perhaps merit definition as a project
> interface so that we can define the problem this is trying to solve and set
> a standard formally once and for all?
> >
> > >Maybe a couple of the various packaging projects can agree and just
> > >set a de facto rule (and document it). That worked out OK for us
> > >with the doc reorganization when we updated the docs.o.o site
> > >templates.
> >
> > I’m happy to facilitate that. Is there some sort of place where such
> standards are recorded? Ie Where do I submit a review to and is there an
> example to reference for the sort of information that should be in it?
> >
>
> The docs team put that info in the spec for the migration. Do we
> have a packaging SIG yet? That seems like an ideal body to own a
> standard like this long term. Short term, just getting some agreement
> on the mailing list would be a good start.


Bah - missed the start of this thread but here's my tuppence

1) +1 for a consistent approach across projects - /usr/share/
sounds like a sensible location - avoiding any complexity with managing
changes made by users in /etc/ for deploy from source use-cases,
and allowing packagers to know where to expect reference/sample config
files to appear during the package build-out/install process.

2) Looking at the Ubuntu packaging for OpenStack projects, we have quite a
few places where oslo-config-generator or oslo-policy-generator is used to
generate sample configuration files as part of the package build; I might
have missed it in my read through of this thread but it would be awesome if
those could be integrated as part of this process as well as the
originating project would then be able to provide some level for assurance
to the content of generated files in downstream distributions.

I'd also be +1 on a packaging SIG; I don't think it will ever be a high
overhead SIG but it sounds like there are common challenges for deployment
projects and distributors which would benefit from shared focus.

Cheers

James
__
OpenStack Development Mailing 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] [charms] evolving the ha interface type

[James Page]

Hi Team

Whilst working on migrating to using Python 3 as the default charm
execution environment, I've hit upon a snag with presentation of data from
principle charms to the hacluster subordinate charm.

Specifically the data presented on the relation is simple str
representation of python dicts which are then parsed used ast in the
hacluster charm.

This has worked OK under Python 2, but due to the non-deterministic
iteration of dict keys, the data presented from the principle charm can
change over time when the ha_joined function is re-exec'ed (such as during
a config-changed hook execution).

I'd like to propose that we move to using json to serialise this data so
that we can used ordered dicts to present data in a consistent fashion.

We need to evolve the interface to deal with this - we could potentially
take two approaches:

a) Attempt to parse presented data using json, fallback to ast for
backwards compat

b) Present a version flag from the hacluster charm, allowing the principle
to switch to the new approach when the required version of the hacluster
charm is presented to it.  We'd still do a) but it would avoid hook
failures in the event that a user does not upgrade hacluster application
instances prior to upgrading principle charms.

Anyway - that's my current thoughts. I have a prototype for a) which works
nicely, but I think adding b) will provide a better UX (thanks gnuoy for
pointing to this solution).

Thoughts?

James
__
OpenStack Development Mailing 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] [charms] Sydney forum user feedback session (Tues@0950)

[James Page]

Hi All

Apologies for the late creation of this pad:

  https://etherpad.openstack.org/p/SYD-forum-charms-ops-feedback

if your planning on attending this session please add your name and any
topics for discussion!

Cheers

James
__
OpenStack Development Mailing 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] [networking-bagpipe] [networking-bgpvpn] missing tarballs for queens milestone 1

[James Page]

Hi

Corey and I have been working through the first Queens milestones for
Ubuntu (and the UCA) - both networking-bagpipe and networking-bgpvpn don't
have published tarballs on tarballs.openstack.org.

Would it be possible to get those up? or we can cut our own from the git
repo for this milestone if that's not possible.

Cheers

James
__
OpenStack Development Mailing 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] [ptg] Dublin PTG proposed track schedule

[James Page]

Hi Thierry

On Thu, 18 Jan 2018 at 10:20 Thierry Carrez  wrote:

> Hi everyone,
>
> Here is the proposed pre-allocated track schedule for the Dublin PTG:
>
>
> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true
>
> The proposed allocation takes into account the estimated group size and
> number of days that was communicated to Kendall and I by the team PTL.
> We'd like to publish this schedule on the event website ASAP, so please
> check that it still matches your needs (number of days, room size vs.
> expected attendance) and does not create too many conflicts. There are
> lots of constraints, so we can't promise we'll accommodate your remarks,
> but we'll do our best.
>

OpenStack Charms team preference would be to have our dedicated room
Wed/Thurs; in Denver we participated in some of the cross projects
discussions such as fast forward upgrades, and I'd not want to have to
fragment our time as a team to accommodate that if possible please!

Cheers

James
__
OpenStack Development Mailing 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] [charms] 16.07 release feature freeze today

[James Page]

Hi All

A (somewhat) late reminder that the feature freeze for the 16.07 charm
release at the end of the month is today; any outstanding feature reviews
need to be fully tested, reviewed and landed by 0800 UTC on the 15th July
(which is the end of the day for those on the west coast of the US).

This has been discussed a-lot in channel (#openstack-charms) - however need
to remember to notify the world as well!

Bug fixes only from tomorrow until the 28th please!

Cheers

James
__
OpenStack Development Mailing 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] [charms] Project mascot

[James Page]

Hi All

As an approved project, we need to provide some ideas for a project mascot
for the Charms project (see [0]).

Some suggestions as discussed on IRC:

1) cobra ('[snake] charming openstack') - which aligns with the Juju logo a
little.
2) kraken ('many armed animal managing openstack') - but I think that falls
into mythical creatures so its probably excluded so maybe octopus instead?

It would be nice to have one or two more ideas - any suggestions?

Cheers

James

[0] http://www.openstack.org/project-mascots
__
OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?

[James Page]

Hi Andrey

On Tue, 2 Aug 2016 at 15:59 Andrey Pavlov  wrote:

> I need to add glance support via storing images in cinder instead of
> local files.
> (This works only from Mitaka version due to glance-store package)
>

OK


> First step I've made here -
> https://review.openstack.org/#/c/348336/
> This patchset adds ability to relate glance-charm to cinder-charm
> (it's similar to ceph/swift relations)
>

Looks like a good start, I'll comment directly on the review with any
specific comments.


> And also it configures glance's rootwrap - original glance package
> doesn't have such code
> (
>   I think that this is a bug in glance-common package - cinder and
> nova can do it themselves.
>   And if someone point me to bugtracker - I will file the bug there.
> )
>

Sounds like this should be in the glance package:

  https://bugs.launchpad.net/ubuntu/+source/glance/+filebug

 or use:

  ubuntu-bug glance-common

on an installed system.


> But main question is about additional configurations' steps -
> Some cinder backends need to store additional files in
> /etc/glance/rootwrap.d/ folder.
> I have two options to implement this -
> 1) relate my charm to glance:juju-info (it will be run on the same
> machine as glance)
> and do all work in this hook in my charm.
> 2) add one more relation to glance - like
> 'storage-backend:cinder-backend' in cinder.
> And write code in a same way - with ability to pass config options.
>

> I prefer option 2. It's more logical and more general. It will allow
> to configure any cinder's backend.
>

+1 the subordinate approach in cinder (and nova) works well; lets ensure
the semantics on the relation data mean its easy to restart the glance
services from the subordinate service if need be.

Taking this a step further, it might also make sense to have the relation
to cinder on the subordinate charm and pass up the data item to configure
glance to use cinder from the sub - does that make sense in this context?

Cheers

James
__
OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?

[James Page]

On Tue, 2 Aug 2016 at 16:54 Andrey Pavlov  wrote:

> James, thank you for your answer.
>

No problem.

I'll file bug to glance - but in current releases glance-charm have to
> do it himself, right?
>

We should be able to add the required bits using an Ubuntu SRU - lets raise
the bug and see exactly what needs to be done, and then we can decide
whether the charm workaround is still required.

I'm not sure that I'm correctly understand your question.
> I suppose that deployment will have glance and cinder on different
> machines.
>

yes - principle charms should typically be deployed in their own units, as
the assume ownership over the filesystem.


> Also there will be one relation between cinder and glance to configure
> glance to store images in cinder.
>

ack

Other steps are optional -
> If cinder is used specific backend that needs additional configuration
> - then it can be done via storage-backend relation (from subordinate
> charm).
> If this backend needs to configure glances' filters or glance's config
> - then it should be done via any subordinate charm to glance (but
> glance doesn't have such relations now).
>

No - we'd need to add a container scoped 'image-backend' relation to
glance, allowing a subordinate to be deployed with glance to install the
required rootwrap configuration, dependencies etc...

You next email covers that - so I'll respond on that there.
__
OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?

[James Page]

Hi Andrey

On Wed, 3 Aug 2016 at 14:35 Andrey Pavlov  wrote:

> Instead of adding one more relation to glance, I can relate my charm to
> new relation 'cinder-volume-service'
>

almost


>
> So there is no more changes in the glance charm.
> And additional in my charm will be -
>
> metadata.yaml -
>
>
>
>
> *subordinate: trueprovides:  image-backend:interface: cinderscope:
> container*
>

Almost - the interface type should be something like 'glance-backend'
matching the type of the container scoped interface we'd need to add to the
glance charm.

provides:
  image-backend:
interface: glance-backend
scope: container

The glance charm needs to interrogate the data presented by the subordinate
charm - I'd suggest one of the data items is 'cinder-backend=True|False' in
which case the glance charm can then set the required configuration option
in the glance-api.conf file (instead of doing that via a relation to cinder
as you proposed in your original changes to glance).


> and then I can relate my charm to glance (and my charm will be installed
> in the same container as glance, so I can configure OS)
> *juju add-relation glance:cinder-volume-service
> scaleio-openstack:image-backend*
>
> This option works for me - I don't need to add something to glance config.
> I'm only need to add files to /etc/glance/rootwrap.d/
> and this option allows to do it.
>

I think the experience would be something like:

  *juju add-relation glance:image-backend  scaleio-openstack:image-backend*

based on my feedback above.  A relation to cinder might not be required
at-all if all glance needs to know is 'use cinder' rather than any other
additional data such as the location of the cinder-api services etc..

As you state - the scaleio-openstack charm can install the required filters
to /etc/glance/rootwrap.d - which is great as it moves the scaleio specific
bits into a specific charm for scaleio (which I like), rather than
overloading and increasing the complexity of the core glance charm.


> I've made additional review - https://review.openstack.org/#/c/350565/
>

Looking today -  I think we can refine things via the review if the overall
design intent is agreed here.

Thanks for your work on this feature!

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

Re: [openstack-dev] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

[James Page]

Hi Carl

On Thu, 19 May 2016 at 21:51 Carl Baldwin  wrote:

> On Thu, May 19, 2016 at 7:09 AM, Doug Hellmann 
> wrote:
> > We have the same issue with version numbers regressing no matter when we
> > cut the next release, so it's up to the team. It might be easier to deal
> > with now while it's fresh in our minds.
> >
> > I would like to update the instructions that were followed to give
> > better information about version numbers. Can someone point me to the
> > documentation that was used for the release process?
>
> Hi, they are here [1].  Built from here [2].
>
> Carl
>

Any update on re-tagging the mitaka release of networking-l2gw with the
correct semantic version?  I'm working on packaging updates for Debian and
Ubuntu, and don't really want to push in 2016.1.0, only to have to then
bump the epoch (versioning semantic in Debian for dealing with changes in
versioning that result in out of order versions) again once the next
semantically versioned release comes out.

Also, what are networking-l2gw's plans for Newton?  I also manage the
packaging of vmware-nsx, which amongst other things, depends on
networking-l2gw so it would be nice to have a co-ordinated release of
networking-l2gw, vmware-nsx (and networking-sfc and tap-as-a-service - but
I'll start another thread on that).

Cheers

James
__
OpenStack Development Mailing 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] [networking-sfc] Newton release plans?

[James Page]

Hi Networking SFC team

I'm trying to get a view on a few Neutron related projects with the
objective of lining up a release in Ubuntu and Debian alongside OpenStack
Newton of vmware-nsx, networking-l2gw, networking-sfc and tap-as-a-service.

What are your plans for Newton? I can push snapshots into Debian/Ubuntu
during development, but it would be nice to know at what point in time
networking-sfc will release a version for Newton so we don't end up with a
dangling snapshot of networking-sfc after the release of Ubuntu 16.10 and
OpenStack Newton.

Cheers

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

Re: [openstack-dev] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

[James Page]

Hi Ihar

On Mon, 8 Aug 2016 at 10:37 Ihar Hrachyshka  wrote:
[...]

> Any update on re-tagging the mitaka release of networking-l2gw with the
> > correct semantic version?  I'm working on packaging updates for Debian
> > and Ubuntu, and don't really want to push in 2016.1.0, only to have to
> > then bump the epoch (versioning semantic in Debian for dealing with
> > changes in versioning that result in out of order versions) again once
> > the next semantically versioned release comes out.
> >
>
> (Hey, neutron release liaison here.)
>

Hey!


> I was thinking we will stick to the (unfortunate) versioning for the
> subproject for the time of Mitaka. But I am happy to switch versioning if
> it makes someone’s life easier. Though I would like to hear a confirmation
> on that from l2gw folks first. (I added some cores to CC.)
>

1.0.0 -> 2016.1.0 -> 3.0.0 is the trick here as 3.0.0 < 2016.1.0; its
possible but I'd rather avoid the epochs in packaging if possible (I might
just skip 2016.1.0 and use a 1.0.0+git snapshot version instead to avoid
that situation).

So I can be flexible, but I suspect that this versioning inconsistency will
cause other deployment types issues as well.


>
> > Also, what are networking-l2gw's plans for Newton?  I also manage the
> > packaging of vmware-nsx, which amongst other things, depends on
> > networking-l2gw so it would be nice to have a co-ordinated release of
> > networking-l2gw, vmware-nsx (and networking-sfc and tap-as-a-service -
> > but I'll start another thread on that).
>
> Note that neither vmware-nsx nor taas is part of neutron stadium, and as
> such are not managed by neutron-release team. You would need to coordinate
> with them separately.
>

OK - I missed they are not part of neutron stadium ([0]); I'll hookup with
those teams individually (already in contact with the vmware-nsx team
anyway).

There was a thread on SFC lately asking for Mitaka release. I guess we
> don’t have any stable branches so far for the subproject.


Yeah - started a different thread on that one.

Cheers

James

[0]
http://docs.openstack.org/developer/neutron/stadium/sub_projects.html#official-sub-project-list
__
OpenStack Development Mailing 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] [charms] nominating thedac for charms-release team

[James Page]

On Mon, 8 Aug 2016 at 18:19 Ryan Beisner  wrote:

> Greetings,
>
> I would like to nominate David Ames  for addition to the
> charms-release team, as he has played a valuable role in the charm release
> processes.  This change will grant privileges such as new stable branch
> creation, among other things necessary to facilitate the charm release
> process.
>

+1
__
OpenStack Development Mailing 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] [charms] out next week/PTL cover

[James Page]

Hi

I'm out of contact from everything electronic next week; back on the 22nd
August.

David Ames (thankyou!) will be covering any Charms PTL related matters in
my absence and generally keeping the wheels on development.

Cheers

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

[openstack-dev] [oslo.context][requirements][ffe] newton - positional 1.1.1 minimum requirement

[James Page]

Hi

Whilst fixing CI test failures/preparing b3 uploads for OpenStack Newton
for Ubuntu, we tripped over [0], symptomatically in Barbican's unit test
suite starting to throw failures when oslo.context was updated to the
latest newton version.

Global requirement currently details 1.0.1 of positional as the minimum
requirement, but 1.1.1 is required to ensure correct parsing of role
headers via oslo.context - basically the roles where being dropped from the
credentials context, resulting in policy enforcement failures.

I've raised a review on requirements to increase the minimum requirement;
as we're in freeze, this will need an exception to be granted.

Cheers

James

[0] https://bugs.launchpad.net/oslo.context/+bug/1620963
[1] https://review.openstack.org/#/c/366631/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.context][requirements][ffe] newton - positional 1.1.1 minimum requirement

[James Page]

On Wed, 7 Sep 2016 at 14:51 Ian Cordasco  wrote:

> Hey James!
>
> There's already a discussion about this with the [requirements] and
> [ffe] tags by Matthew Thode. Could we centralize the discussion on
> that thread please?
>

Of course - missed that whilst eating lunch!
__
OpenStack Development Mailing 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] [requirements][FFE] global-requirements update to positional to 1.1.1

[James Page]

On Wed, 7 Sep 2016 at 14:30 Ian Cordasco  wrote:
[...]

> https://review.openstack.org/366631
> >
> > The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> > current minimum requirement) results in various unit test failures in
> > barbican, related to parsing of request headers in generated contexts
> > for unit testing. Updating to 1.1.1 resolves this issue.
>
> So I take it someone has verified that the request headers used in the
> faked(?) contexts in these tests will never be seen in the real world
> then? I looked at the tests that James linked in the barbican channel
> when they were looking for help debugging this and those looked like
> *functional* tests, not unit tests. That doesn't give me any
> confidence that this is *just* a testing issue.
>
> > This is specifically affecting barbican and RDO testing (from discussion
> > and the review).
>
> I believe this is also affecting Ubuntu's backing of Newton-3, but
> James can correct me if I'm wrong.
>

We're unblocked by upgrading to positional 1.1.1 (the CI build failure was
detected a week or so ago, but with b3 also arriving and it not being
entirely obvious what the problem was its taken a while to figure out);
I've enforced this as a versioned package dependency for oslo.context, so
upgrades from mitaka will get the right version as well.
__
OpenStack Development Mailing 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] [puppet] today was a bad day for CI

[James Page]

On Fri, 9 Sep 2016 at 01:17 Emilien Macchi  wrote:
[...]

> 3) Disable Ironic testing on Ubuntu. Packages are broken in recent
> Newton upgrade. They are working on it.
>

Ironic packaging issue fixed and released to newton-updates; that will
teach me to spend a morning tidying up old bugs :).


> 4) Enable br_netfilter kernel module on Ubuntu.
> See https://bugs.launchpad.net/cloud-archive/+bug/1621651
> Even if it's not critical, it's a nice-to-have because it removed the
> ERROR that we had in neutron logs. We'll see how the bug report evolve
> and maybe remove this workaround.
>

I've moved this to:

  https://bugs.launchpad.net/cloud-archive/+bug/1621854

as its a separate issue to the os-vif version problem (see below).

6) Disable linuxbridge on scenario003 for Ubuntu
> Also see https://bugs.launchpad.net/cloud-archive/+bug/1621651


os-vif updated to 1.2.1 and released to newton-updates; not detected by our
version checker as its was not in upper-constraints until recently.
__
OpenStack Development Mailing 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] [charms] PTL candidacy

[James Page]

Hi

I would like to announce my candidacy for PTL of the OpenStack Charms
project (see [0]).

I'm the incumbent and first PTL of this project, which joined the OpenStack
project this year;  Right now we have around 30 charms for deploying
various parts of OpenStack, with an active core team 100% populated by
Canonical.

We're slowly incubating contribution from outside of this team - this cycle
I want to focus on changing that; specifically I think we have shortcomings
in engaging new developers, as getting into OpenStack charm development can
be high cost - the route to testing your charm change prior to submission
currently presents various options, and I want to focus on ensuring that
anyone with a reasonably specified machine can get started deploying
OpenStack and hacking on the OpenStack charms, enabling both end-users and
developers to have a better start in using and understanding the OpenStack
Charms.

I will continue to drive cross charm initiatives; specifically I think
Python 3 support is a key objective during the Ocata cycle, and we should
aim
to have that in place as early in cycle as possible.

I also look forward to working collaboratively with other deployment
projects
within the OpenStack project.

I look forward to helping steer the project during the Ocata cycle, and
helping to incubate the developer and user community around the OpenStack
Charms!

Cheers

James

[0] https://review.openstack.org/368678
__
OpenStack Development Mailing 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] [charms] Dublin PTG devroom

[James Page]

Hi Team

The Dublin PTG is not so far away now, so lets start on the agenda for our
Devroom:

  https://etherpad.openstack.org/p/DUB-charms-devroom

We had a fairly formal agenda of design related topics in Denver for the
first day, and spent most of the second day mini-sprinting on various
features/bugs/issues/niggles etc...

I think it worked well - what do others think?

Please add topics to the pad.

Cheers

James
__
OpenStack Development Mailing 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] [charms] PTL for Rocky

[James Page]

Hi All



It will (probably) come as no surprise that I'd like to announce

my candidacy for PTL of OpenStack Charms [0]!


We've made some good progress in the last cycle with some general

housekeeping across the charms set, including removal of untested

and generally unused database and messaging configurations. We've

also finally managed to complete the deprecation of the Ceph charm

with a well documented migration path to the newer Charms for

operators to use.


This is all great but we still have more housekeeping todo!


Specifically we need to complete migration to using Python 3

as the default execution environment for charms (this was started

during Queens, but is not yet complete).


I'd like to see more depth in the networking configurations and

choices the charms present (we already have specs raised for

Dynamic Routing and Network Segment support) and I think these

will appeal to operators with more complex networking requirements

for OpenStack.


I think we also need to finish the work we started last year on

improving the Telemetry storage; Aodh, Gnocchi and Ceilometer are

all looking in pretty good shape now, but we need to add Panko to

the fold!


I still think we have a bit of an issue with level of entry to

writing a charm - it turns out that writing a charm is dead easy;

writing unit tests is also pretty easy and familiar with anyone

who writes any amount of Python; enabling full functional testing

of a charm is much harder.  Our historic tool choice (amulet) does

not help in this area and I look forward to working with the dev

team this cycle to move us onto something that's a) more directly

maintainable and b) easier to engage with as we bring new charms

and features onboard.


I look forward to helping steer the project during the Rocky cycle!


Cheers


James

[0] https://review.openstack.org/541306
__
OpenStack Development Mailing 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] [ptg] Track around release cycle, consumption models and stable branches

[James Page]

Hi Thierry

On Wed, 7 Feb 2018 at 11:42 Thierry Carrez  wrote:

> Hi everyone,
>
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
>
> I have hesitated to propose it earlier, as it sounds like a topic that
> should be discussed with the wider community at the Forum. And it will,
> but it feels like this needs a deeper pre-discussion in a productive
> setting, and tonyb and eumel8 have been proposing that topic on the
> missing topics etherpad[1], so we might as well take some time at the
> PTG to cover that.
>
> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.


I would be interested in participating in this (and I'll still be around
Tuesday PM).

Cheers

James
__
OpenStack Development Mailing 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] [charms] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[James Page]

+1 from me

On Thu, 8 Feb 2018 at 18:23 Billy Olsen  wrote:

> Dmitrii easily gets a +1 from me!
>
> On 02/08/2018 09:42 AM, Alex Kavanagh wrote:
> > Hi
> >
> > I'd like to propose Dmitrii Shcherbakov to join the launchpad
> > "OpenStack Charmers" team.  He's done some tremendous work on existing
> > the charms, has developed some new ones, and has really developed his
> > understanding of configuring and implementing OpenStack.  I think he'd
> > make a great addition to the team.
> >
> > Thanks
> > Alex.
> >
> >
> > --
> > Alex Kavanagh - Software Engineer
> > Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms]

[James Page]

+1

On Wed, 14 Feb 2018 at 11:29 Liam Young  wrote:

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
>
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> OpenStack Development Mailing 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] [charms]

[James Page]

+1

On Wed, 14 Feb 2018 at 11:29 Liam Young  wrote:

> Hi,
>
> I would like to propose that we do not support the notifications
> method for automatically creating DNS records in Queens+. This method
> for achieving Neutron integration has been superseded both upstream
> and in the charms. By removing support for it in Queens we prevent the
> charm from attempting to make designate v1 api calls for Queens+ which
> is a positive thing given it will have been removed (
>
> https://docs.openstack.org/releasenotes/designate/queens.html#critical-issues
> ).
>
> Thanks
> Liam
>
> __
> OpenStack Development Mailing 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] [charms] [ptg] charms dinner

[James Page]

Hi Team

As I'm only managing to get to the PTG for Mon/Tues lets schedule a dinner
for Monday night; I'll sort out a venue - lemme know direct this week if
you'll be coming along!

Cheers

James
__
OpenStack Development Mailing 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] [charms] queens support release date

[James Page]

Hi All

We're not quite fully baked with Queens testing for the OpenStack charms
for this week so we're going to push back a week to the 8th March to allow
pre-commit functional testing updates to land.

Cheers

James
__
OpenStack Development Mailing 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][charms] Openstack + OVN

[James Page]

Hi Aakash

On Sun, 11 Mar 2018 at 19:01 Aakash Kt  wrote:

> Hi,
>
> I had previously put in a mail about the development for openstack-ovn
> charm. Sorry it took me this long to get back, was involved in other
> projects.
>
> I have submitted a charm spec for the above charm.
> Here is the review link : https://review.openstack.org/#/c/551800/
>
> Please look in to it and we can further discuss how to proceed.
>

I'll feedback directly on the review.

Thanks!

James
__
OpenStack Development Mailing 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] [ptg][sig][upgrades] Upgrade SIG

[James Page]

Hi All

I finally got round to writing up my summary of the Upgrades session at the
PTG in Dublin (see [0]).

One outcome of that session was to form a new SIG centered on Upgrading
OpenStack - I'm pleased to announce that the SIG has been formally accepted!

The objective of the Upgrade SIG is to improve the overall upgrade process
for OpenStack Clouds, covering both offline ‘fast-forward’ upgrades and
online ‘rolling’ upgrades, by providing a forum for cross-project
collaboration between operators and developers to document and codify best
practice for upgrading OpenStack.

If you are interested in participating in the SIG please add your details
to the wiki page under 'Interested Parties':

  https://wiki.openstack.org/wiki/Upgrade_SIG

I'll be working with the other SIG leads to setup regular IRC meetings in
the next week or so - we expect to alternate between slots that are
compatible with all time zones.

Regards

James

[0]
https://javacruft.wordpress.com/2018/03/16/winning-with-openstack-upgrades/
[1] https://governance.openstack.org/sigs/
__
OpenStack Development Mailing 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] [sig] [upgrades] inaugural meeting minutes & vancouver forum

[James Page]

Hi All

Lujin, Lee and myself held the inaugural IRC meeting for the Upgrades SIG
this week (see [0]). Suffice to say that, due to other time pressures,
setup of the SIG has taken a lot longer than desired, but hopefully now we
have the ball rolling we can keep up a bit of momentum.

The Upgrades SIG intended to meet weekly, alternating between slots that
work for (hopefully) all time zones:

   http://eavesdrop.openstack.org/#Upgrades_SIG

That said, we'll skip next weeks meeting due to the OpenStack Summit and
Forum in Vancouver, where we have a BoF on the schedule (see [1]) instead.

If you're interested in OpenStack Upgrades the BoF and Erik's sessions on
Fast Forward Upgrades (see [2]) should be on your schedule for next week!

Cheers

James


[0]
http://eavesdrop.openstack.org/meetings/upgrade_sig/2018/upgrade_sig.2018-05-15-09.06.html
[1]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21855/upgrade-sig-bof
[2]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=upgrades
__
OpenStack Development Mailing 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] [sig] [upgrades] inaugural meeting minutes & vancouver forum

[James Page]

Hi All

Lujin, Lee and myself held the inaugural IRC meeting for the Upgrades SIG
this week (see [0]). Suffice to say that, due to other time pressures,
setup of the SIG has taken a lot longer than desired, but hopefully now we
have the ball rolling we can keep up a bit of momentum.

The Upgrades SIG intended to meet weekly, alternating between slots that
work for (hopefully) all time zones:

   http://eavesdrop.openstack.org/#Upgrades_SIG

That said, we'll skip next weeks meeting due to the OpenStack Summit and
Forum in Vancouver, where we have a BoF on the schedule (see [1]) instead.

If you're interested in OpenStack Upgrades the BoF and Erik's sessions on
Fast Forward Upgrades (see [2]) should be on your schedule for next week!

Cheers

James


[0]
http://eavesdrop.openstack.org/meetings/upgrade_sig/2018/upgrade_sig.2018-05-15-09.06.html
[1]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21855/upgrade-sig-bof
[2]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=upgrades
__
OpenStack Development Mailing 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] [charms] regular bug day

[James Page]

Hi Folks

We have an organised bug day prior to the OpenStack Summit in Barcelona; I
felt that this focused everyone onto collaborating on bugs in a good way,
and gave us a great checkpoint on what the key issues are that people are
hitting and reporting back on the charms.

I'd like to proposed that we have a regular month charm bug day on the
first Thursday of every month - starting this week on the 1st of December!

I'll (normally) send out a reminder a week in advance to remind everyone!

Cheers

James
__
OpenStack Development Mailing 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] [charms] irc meetings for next few weeks

[James Page]

Hi All

As we're approaching a period where quite a few people will be having time
off, I'm cancelling the IRC meetings on Mondays (1000 and 1700 on alternate
weeks) until the 9th January at 1700 UTC - at which point we'll resume
normal service, with the next meeting after that at 1000 UTC on the 16th.

Have a nice break if you're taking some time out!

Cheers

James
__
OpenStack Development Mailing 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] [charms] bug squash thursdays

[James Page]

Hi Team

Our last (and only) bug day was quite popular/successful, so lets try and
have one focus day on bugs a month.

So from January, the first Thursday of the month will officially be 'Charm
Bug Squash Day'.

The objective of the day is to triage any untouched bugs, sift through
triaged bugs in priority order and fix any long standing niggles and issues
in the charm set!

See you all on #openstack-charms on the 5th January for some bug triage and
fixing fun!

Cheers

James

P.S. please also continue to look at bugs on days other than the first
Thursday of the month!
__
OpenStack Development Mailing 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] [charms] ceilometer metering and event time-to-live defaults

[James Page]

Hi All

In the current ceilometer charms, we retain all ceilometer data
indefinitely;  the TTL can be overridden by users using configuration
options, but to me it feels like maybe retaining all data forever by
default is a trip hazard to users, and the actions required to backout of a
full DB for not that nice:

  https://bugs.launchpad.net/charms/+source/ceilometer/+bug/1652856

Any thoughts? What TTL defaults do deployments (and other deployment tools)
typically use for ceilometer data?

Cheers

James
__
OpenStack Development Mailing 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] [charms] ceilometer metering and event time-to-live defaults

[James Page]

Hi Julien

On Tue, 3 Jan 2017 at 09:17 Julien Danjou  wrote:

> > In the current ceilometer charms, we retain all ceilometer data
> > indefinitely;  the TTL can be overridden by users using configuration
> > options, but to me it feels like maybe retaining all data forever by
> > default is a trip hazard to users, and the actions required to backout
> of a
> > full DB for not that nice:
> >
> >   https://bugs.launchpad.net/charms/+source/ceilometer/+bug/1652856
> >
> > Any thoughts? What TTL defaults do deployments (and other deployment
> tools)
> > typically use for ceilometer data?
>
> The default are set to no expiry because we felt like deleting data by
> default is not a good choice. If there's a consensus that the default
> should be something else, maybe that could be fixed directly upstream.
>

Yeah - that's why we've had no expiry as a default as well.

I'm not convinced we need to switch - just felt like we could do more in a
number of ways to help users not trip over this.


> Now, I'd like to emphasize that this part of Ceilometer is officially
> deprecated, so I hope not too much effort is put into this, and more in
> the new projects that are now recommended (i.e. Gnocchi). :-)


Indeed - however the charms support older versions of OpenStack as well, so
to an extent we have to look back to the past as well as forward to the
future!

Cheers

James
__
OpenStack Development Mailing 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] [charms] bug day this thursday

[James Page]

Hi All

Just a quick reminder that this Thursday (5th January) is our first bug day
for charms of the year.

Objective is to blast through the un-triaged bug backlog assigning some
initial priorities and then fixup as many bugs as possible!

Please co-ordinate via #openstack-charms so we don't all tread on each
others toes :-)

Cheers

James
__
OpenStack Development Mailing 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] [snaps] alternative distribution approach for OpenStack

[James Page]

Hi All

I’ve been working with a few folk over the last few months to see if snaps
(see [0]) might be a good alternative approach to packaging and
distribution of OpenStack.

As OpenStack projects are Python based, producing snaps has been relatively
trivial with the snapcraft python plugin, which supports all of the tooling
that would be used in a deployment from source (pip, constraints etc…).
Thanks goes to Sam Yaple for his work on the Python plugin to support all
of the required features for snapping OpenStack!

The resulting snap for each project is self contained, with all required
dependencies baked into the snap, rather than using system provided
dependencies from the hosting operating system.

This means that the snap is directly aligned with each OpenStack project
from a software component perspective - avoiding the juggling act that
distro’s have to do each cycle to ensure the entire dependency chain for
OpenStack is lined up correctly.

Additionally, we can also include other non-Python dependencies in a snap -
for example the nova-hypervisor snap includes dnsmasq, ipset and
openvswitch tools built from source as part of the snap build process.  I’d
envision extending that list to include libvirt (but that was a bit too
much to bite off in the first few cycles or work).

>From an operations perspective, snaps are transactionally applied on
installation, which means that if an upgrade fails, the snap will be rolled
back to the last known good version.

Installs and upgrades are also fast, as the snap internally is a read only
squashfs filesystem which is simply mounted alongside the existing
installed snap, daemons are stopped, pointers switched and daemons
restarted.

Snaps typically run a confined environment, sandboxed using AppArmor and
Seccomp on Ubuntu. Snapd (the management daemon for snaps) provides a
number of interfaces to allow users to grant snaps permissions to perform
different operations on the host OS - for example network and firewall
control (the full interface list is much longer  - see [3]).

We’ve leveraged (and contributed to) a number of these interfaces to
support the nova-hypervisor snap.

Snap confinement means that snaps don’t (by default) have access to /etc -
instead configuration is supplied in a snap specific location on the
filesystem (take a look in the README of a snap for how that works at a
high level).  That location essentially mirrors /etc for the snap, which
should make adoption relatively easy for existing deployment tooling.

Snaps are also by design distro agnostic - so long as snapd has been ported
and the kernel version is sufficient to support the required security
features things should just work (but we’ve not tried that out just yet!).

We’ve snapped a few core components (see [1]) - enough to produce an
all-in-one install which you can try on Ubuntu 16.04 using snap-test [2] to
get a flavor of how things will look as this work develops further.


The source for each snap is being developed on OpenStack infra, however the
final build and publication to the snap store is being done on Launchpad
using git repo mirroring and automatic snap building on each change.   This
includes arm64 and ppc64el architecture builds.

Updates are only pushed to the edge channel on the snapstore today - we’ll
need to figure out a good channel strategy as things mature to include
great CI/CD as well as concurrent support for multiple OpenStack releases.

Anyway - that’s probably enough words for now!

We’re all hanging out in #openstack-snaps on Freenode IRC so come find us
if you have any questions!

Cheers

James

[0] http://snapcraft.io

[1] https://github.com/search?q=org%3Aopenstack+snap

[2] https://github.com/openstack-snaps/snap-test
[3] http://snapcraft.io/docs/reference/interfaces
__
OpenStack Development Mailing 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] [charms][ptl] PTL candidacy

[James Page]

Hi All

I would like to announce my candidacy for PTL of the OpenStack Charms
project.

Over the Ocata cycle, we've been incubating the community of developers
around
the Charms, with new charms for Murano, Trove, Mistral and CloudKitty all
due
to be included in the release in February.

We've also started to engage successfully with the vendor ecosystem around
OpenStack, with PLUMgrid, Calico and 6wind all working towards aligment and
inclusion in the OpenStack Charm release.

This is all helping to diversify the development community around the
Charms.

I'll continue to work to support the wider ecosystem adoption of the Charms
as a great way to deploy and manage OpenStack.

We've made some in-roads into improving the developer experience for charm
authors, but I feel there is still progress to be made so I will continue to
focus on this aspect of the project during the Pike cycle.

I look forward to working with the team and steering the project for another
cycle!

Cheers

James
__
OpenStack Development Mailing 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] [charms] Thursday 2nd February - Bug Day!

[James Page]

Hi Team

Just a quick reminder that next Thursday marks our second bug day for the
year.

Please focus on triage and resolution of bugs across the openstack charms -
the new bugs URL is in the topic in #openstack-charms on Freenode IRC.

Happy bug hunting!

Cheers

James
__
OpenStack Development Mailing 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] [charms] minutes from todays IRC meeting

[James Page]

Hi All

Here are the links from todays Charms IRC meeting:

 Agenda:
https://etherpad.openstack.org/p/openstack-charms-weekly-meeting-20170129
 Minutes:
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.html
 Minutes (text):
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.txt
 Log:
http://eavesdrop.openstack.org/meetings/charms/2017/charms.2017-01-30-10.03.log.html

Our next team meeting is at 1700 UTC on the 6th February in
#openstack-meeting-4

Cheers

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