Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

[David Gurtner]

I finally got around to split the RGW test into 3 steps: 1) mons/osds/keys 2) 
rgw/apache 3) keystone and got the tests for that to pass on Ubuntu. But it 
seems there is new EPEL dependency issue since yesterday:
https://review.openstack.org/#/c/252664/

David, maybe you wan't to rebase your changes on top of this for easier 
debugging?

- Original Message -
> I pushed an overly optimistic review [1] for updating Openstack to Liberty.
> Haven't had the time to look back at it yet.
> 
> The general idea was to defer the repository setup to openstack_extras and
> pull in
> the keystone setup mostly as-is directly from puppet-openstack-integration.
> 
> [1]: https://review.openstack.org/#/c/251531/
> 
> 
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> On Wed, Dec 2, 2015 at 5:45 AM, David Gurtner  wrote:
> 
> > So from the discussion I gather we should do the following:
> >
> > - Update the jobs to run Infernalis
> > - Split the RGW jobs into smaller chunks where one tests just the RGW and
> > another one tests Keystone integration
> > - Use Liberty (or at least Kilo) for the Keystone integration job
> > - Split the tests more to have a test specifically for cephx functionality
> > - re-enable the tests for CentOS once they work again
> >
> > Open points from my POV are:
> >
> > - should we test older Ceph versions via Jenkins (this would increase the
> > runtime again)
> > - should we still test CentOS 6 and Ubuntu 12.04
> > - if yes, where
> > - should we port more of the deprecated rspec-puppet-system tests? things
> > I can think of are: 1) the profile tests 2) the
> > scenario_node_terminus/hiera tests
> >
> > I'm happy to start working on the split of tests and the
> > Infernalis/Liberty version bump tonight.
> >
> > Cheers,
> > David
> >
> > - Original Message -
> > > Hey Adam,
> > >
> > > A bit late here, sorry.
> > > Ceph works fine with OpenStack Kilo but at the time we developed the
> > > integration tests for puppet-ceph with Kilo, there were some issues
> > > specific to our test implementation and we chose to settle with Juno
> > > at the time.
> > >
> > > On the topic of CI, I can no longer sponsor the third party CI
> > > (through my former employer, iWeb) as I am with Red Hat now.
> > > I see this as an opportunity to drop the custom system tests with
> > > vagrant and instead improve the acceptance tests.
> > >
> > > What do you think ?
> > >
> > >
> > > David Moreau Simard
> > > Senior Software Engineer | Openstack RDO
> > >
> > > dmsimard = [irc, github, twitter]
> > >
> > >
> > > On Mon, Nov 23, 2015 at 6:45 PM, Adam Lawson  wrote:
> > > > I'm confused, what is the context here? We use Ceph with OpenStack Kilo
> > > > without issue.
> > > >
> > > > On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:
> > > >>
> > > >> Last I remember, David Gurtner tried to use Kilo instead of Juno but
> > > >> he bumped into some problems and we settled for Juno at the time [1].
> > > >> At this point we should already be testing against both Liberty and
> > > >> Infernalis, we're overdue for an upgrade in that regard.
> > > >>
> > > >> But, yes, +1 to split acceptance tests:
> > > >> 1) Ceph
> > > >> 2) Ceph + Openstack
> > > >>
> > > >> Actually learning what failed is indeed challenging sometimes, I don't
> > > >> have enough experience with the acceptance testing to suggest anything
> > > >> better.
> > > >> We have the flexibility of creating different logfiles, maybe we can
> > > >> find a way to split out the relevant bits into another file.
> > > >>
> > > >> [1]: https://review.openstack.org/#/c/153783/
> > > >>
> > > >> David Moreau Simard
> > > >> Senior Software Engineer | Openstack RDO
> > > >>
> > > >> dmsimard = [irc, github, twitter]
> > > >>
> > > >>
> > > >> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward 
> > wrote:
> > > >> > I think I have a good lead on the recent failures in openstack /
> > swift /
> > > >> > radosgw integration component that we have since disabled. It looks
> > like
> > > >> > there is a oslo.config version upgrade conflict in the Juno repo we
> > > >> > where
> > > >> > using for CentOS. I think moving to Kilo will help sort this out,
> > but at
> > > >> > the
> > > >> > same time I think it would be prudent to separate the Ceph v.s.
> > > >> > OpenStack
> > > >> > integration into separate jobs so that we have a better idea of
> > which is
> > > >> > a
> > > >> > problem. If there is census for this, I'd need some direction /
> > help, as
> > > >> > well as set them up as non-voting for now.
> > > >> >
> > > >> > Looking into this I also found that the only place that we do
> > > >> > integration
> > > >> > any of the cephx logic was in the same test so we will need to
> > create a
> > > >> > component for it in the ceph integration as well as use it in the
> > > >> > OpenStack
> > > >> > side.
> > > >> >
> > > >> > Lastly un-winding the integration failure seemed overly complex.

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

[Li, Xiaoyan]

> -Original Message-
> From: Ben Swartzlander [mailto:b...@swartzlander.org]
> Sent: Friday, December 4, 2015 2:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick
> 
> On 12/03/2015 07:40 AM, Duncan Thomas wrote:
> > On 3 December 2015 at 11:14, Li, Xiaoyan  > > wrote:
> >
> > Just to clear the data operations cinder needs to touch plaintext
> > data are:
> >   1) Create volume from glance image
> >   2) Create glance image from volume
> >   3) Retype encrypted volumes. That is to change a volume from
> > unencrypted to encrypted, or vice visa.
> >
> > Backup/Restore doesn't need to decrypt data.
> >
> >
> > Backup / restore doesn't currently decrypt the data. There are some
> > people commenting that it is not useful for DR work to have a backup
> > that requires keys from a key service that is itself not backed up, so
> > there may be some proposal incoming about not encrypting backups, or
> > else giving them their own key rather than require access to the
> > original volume key during restore - needing that access also makes
> > things like re-keying the original volume difficult/impossible.
> >
> > Again, we have multiple use-cases for encryption, and they are not all
> > going to be solved by solved by draconian dictates that there shall
> > only be one way of doing things.
> 
> There are other very good reasons for multiple encryption keys for
> different purposes. Client side data encryption is known to prevent server-
> side compression and deduplication technologies from working at all, and
> it makes backups wildly less efficient. The upshot is that if choose to do
> implement security by encryption everything in the guest or hypervisor
> rather than in the storage controller, you're going to spend a ton more on
> disks.
> 
> Assuming your threat model involves evil people sniffing network wires,
> and pulling disks from machines in the datacenter, rather than assuming to
> storage admin himself is evil, you can devise schemes that involve separate
> encryption for in-flight data and at-rest data which allow the storage
> controller to do compression and deduplication and store your data in both
> a secure AND EFFICIENT manner.
> 
> The above isn't a future fantasy -- there are storage controllers that do this
> TODAY with unmodified cinder and nova. You just need a storage
> controller that features full-disk-encryption and also transport level
> security (such as blocks over Kerberized NFS) as well as the compression
> and deduplication technologies which are quickly becoming standardized.

Yeah, another point I can think is that when backup restores, it can use 
different encryptions, like key, key_size, and algorithm.
 
> 
> -Ben
> 
> 
> >
> _
> _
> >  OpenStack Development Mailing 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] [Monasca][vitrage] Vitrage project

[AFEK, Ifat (Ifat)]

Hi Roland,

We created a blueprint for Vitrage-Monasca integration: 
https://blueprints.launchpad.net/vitrage/+spec/monasca-integration.
We will be happy to get your comments about it.

Thanks,
Ifat.


> -Original Message-
> From: Hochmuth, Roland M [mailto:roland.hochm...@hpe.com]
> Sent: Thursday, November 19, 2015 8:51 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Monasca][vitrage] Vitrage project
> 
> Hi Ifat, Thanks for the heads-up. We will start reviewing your
> blueprints and providing feedback.
> 
> With respect to the support for AODH, I'm assuming that you are
> referring too,
> https://review.openstack.org/#/c/244049/2/specs/mitaka/manage-
> ceilometer-al
> arms.rst. For adding support for Monasca, a Vitrage Notifier would be
> developed for Monasca.
> 
> In the diagram at, https://wiki.openstack.org/wiki/Vitrage, it shows
> the Synchronizer collecting data, such as OpenStack notifications,
> which usually implies RabbitMQ. With the Ceilosca effort,
> https://www.openstack.org/summit/tokyo-
> 2015/videos/presentation/ceilometer-
> monascaceilosca and https://github.com/openstack/monasca-ceilometer, we
> are planning on sending OpenStack Notifications from Ceilometer to
> Monasca. Monasca will then publish to the Kafka queue. Would you be
> interested in consuming events from Kafka by the Synchronizer to reduce
> the load on RabbitMQ?
> 
> In the use cases you discuss getting health/status information about a
> switch and correlating problems to VMs. But, in the diagram only SDN
> Controller, Heat, Cinder and Nova are shown. Are you planning on
> receiving health/status information from other sources? Monasca is
> processing metrics for many components, such as the physical
> infrastructure used for running the cloud and for OpenStack resources,
> and generating alarms. For example, in your use case, Monasca could be
> monitoring the physical switch and creating alarms. Should alarms that
> Monasca creates be a source for the Vitrage Synchronizer?
> 
> Regards --Roland
> 
> 
> On 11/17/15, 3:02 AM, "AFEK, Ifat (Ifat)"  lucent.com>
> wrote:
> 
> >Hi Monasca developers,
> >
> >As you might have heard in Mitaka Summit, we have started a new
> project
> >named Vitrage[1]. We would like it to be the Openstack RCA (Root Cause
> >Analysis) Engine for organizing, analyzing and expanding OpenStack
> >alarms & events, yielding insights regarding the root cause of
> problems
> >and deducing the existence of problems before they are directly
> detected.
> >
> >We are now in the process of reviewing the blueprints[2] that we wish
> >to implement in mitaka. At the first stage of the implementation we
> >plan to integrate with AODH alarms. In the next phase, we would like
> to
> >check how we can integrate with Monasca as well. We would be happy to
> >get your reviews for our blueprints, to make sure our architecture
> >matches this future integration.
> >
> >Your feedback would be highly appreciated.
> >
> >[1] https://wiki.openstack.org/wiki/Vitrage
> >[2] https://blueprints.launchpad.net/vitrage
> >
> >Thanks,
> >Ifat Afek.
> >
> >
> >
> >__
> _
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [ironic]"No valid host was found" when creating node in Ironic

[Zhi Chang]

Hi, all
I install devstack with Ironic in physical machine. And I want to deploy a 
another physical machine which IPMI info is "username:root password:12345 
ip_address: 192.168.0.100". I use this command "ironic node-create -c 
d5f2dee1-f5bc-409e-a9be-a3ae5c392cfa -d ipmi_tool -p ipmi_username=root -p 
ipmi_address=192.168.0.100 -p ipmi_password=12345 -n testing" to create a node 
in Ironic. There is an error when I run the command. It says "No valid host was 
found. Reason: No conductor service registered which supports driver ipmi_tool. 
(HTTP 400)". What should I do to resolve this problem? Or, what should I do if 
I want to deploy a physical machine by using Ironic? 




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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Thierry Carrez]

Dmitry Tantsur wrote:
> 
> 2015-12-04 18:26 GMT+01:00 Doug Hellmann  >:
> 
> Excerpts from Dmitry Tantsur's message of 2015-12-04 17:38:43 +0100:
> > Hi!
> >
> > As you all probably know, we've switched to reno for managing release
> > notes. What it also means is that the release team has stopped managing
> > milestones for us. We have to manually open/close milestones in
> > launchpad, if we feel like. I'm a bit tired of doing it for inspector,
> > so I'd prefer we stop it. If we need to track release-critical patches,
> > we usually do it in etherpad anyway. We also have importance fields for
> > bugs, which can be applied to both important bugs and important 
> features.
> >
> > During a quick discussion on IRC Sam mentioned that neutron also dropped
> > using blueprints for tracking features. They only use bugs with RFE tag
> > and specs. It makes a lot of sense to me to do the same, if we stop
> > tracking milestones.
> >
> > For both ironic and ironic-inspector I'd like to get your opinion on the
> > following suggestions:
> > 1. Stop tracking milestones in launchpad
> > 2. Drop existing milestones to avoid confusion
> 
> Please don't delete anything older than Mitaka.
> 
> 
> Do you have any hints how to not confuse users in this case?

I think what Doug means is you should not delete existing closed
milestones like:
https://launchpad.net/ironic/kilo/2015.1.0
or:
https://launchpad.net/ironic/liberty/4.2.0
since we use the Launchpad pages there as the list of features and bugs
fixed for those pre-reno releases.

Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [magnum]storage for docker-bootstrap

[Kai Qiang Wu]

HI Hua,

From my point of view, not everything needed to be put in container. Let's
make the initial start (be simple)to work and then discussed other options
if needed in IRC or weekly meeting.


Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   王华 
To: Egor Guz 
Cc: "openstack-dev@lists.openstack.org"

Date:   07/12/2015 10:10 am
Subject:Re: [openstack-dev] [magnum]storage for docker-bootstrap



Hi all,

If we want to run etcd and flannel in container, we will
introduce docker-bootstrap which makes setup become more complex as Egor
pointed out. Should we pay for the price?

On Sat, Nov 28, 2015 at 8:45 AM, Egor Guz  wrote:
  Wanghua,

  I don’t think moving flannel to the container is good idea. This is setup
  great for dev environment, but become too complex from operator point of
  view (you add extra Docker daemon and need extra Cinder volume for this
  daemon, also
  keep in mind it makes sense to keep etcd data folder at Cinder storage as
  well because etcd is database). flannel has just there files without
  extra dependencies and it’s much easy to download it during cloud-init ;)

  I agree that we have pain with building Fedora Atomic images, but instead
  of simplify this process we should switch to another more “friendly”
  images (e.g. Fedora/CentOS/Ubuntu) which we can easy build with disk
  builder.
  Also we can fix CoreOS template (I believe people more asked about it
  instead of Atomic), but we may face similar to Atomic issues when we will
  try to integrate not CoreOS products (e.g. Calico or Weave)

  —
  Egor

  From: 王华 mailto:wanghua.hum...@gmail.com>>
  Reply-To: "OpenStack Development Mailing List (not for usage questions)"
  >
  Date: Thursday, November 26, 2015 at 00:15
  To: "OpenStack Development Mailing List (not for usage questions)" <
  openstack-dev@lists.openstack.org>
  Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap

  Hi Hongbin,

  The docker in master node stores data
  in /dev/mapper/atomicos-docker--data and metadata
  in /dev/mapper/atomicos-docker--meta. /dev/mapper/atomicos-docker--data
  and /dev/mapper/atomicos-docker--meta are logic volumes. The docker in
  minion node store data in the cinder volume,
  but /dev/mapper/atomicos-docker--meta
  and /dev/mapper/atomicos-docker--meta are not used. If we want to
  leverage Cinder volume for docker in master, should we
  drop /dev/mapper/atomicos-docker--meta
  and /dev/mapper/atomicos-docker--meta? I think it is not necessary to
  allocate a Cinder volume. It is enough to allocate two logic volumes for
  docker, because only etcd, flannel, k8s run in the docker daemon which
  need not a large amount of storage.

  Best regards,
  Wanghua

  On Thu, Nov 26, 2015 at 12:40 AM, Hongbin Lu mailto:hongbin...@huawei.com>> wrote:
  Here is a bit more context.

  Currently, at k8s and swarm bay, some required binaries (i.e. etcd and
  flannel) are built into image and run at host. We are exploring the
  possibility to containerize some of these system components. The
  rationales are (i) it is infeasible to build custom packages into an
  atomic image and (ii) it is infeasible to upgrade individual component.
  For example, if there is a bug in current version of flannel and we know
  the bug was fixed in the next version, we need to upgrade flannel by
  building a new image, which is a tedious process.

  To containerize flannel, we need a second docker daemon, called
  docker-bootstrap [1]. In this setup, pods are running on the main docker
  daemon, and flannel and etcd are running on the second docker daemon. The
  reason is that flannel needs to manage the network of the main docker
  daemon, so it needs to run on a separated daemon.

  Daneyon, I think it requires separated storage because it needs to run a
  separated docker daemon (unless there is a way to make two docker daemons
  share the same storage).

  Wanghua, is it possible to leverage Cinder volume for that. Leveraging
  external storage is always preferred [2].

  [1]
  
http://kubernetes.io/v1.1/docs/getting-started-guides/docker-multinode.html#bootstrap-docker

  [2] http://www.projectatomic.io/docs/docker-storage-recommendation/

  Best regards,
  Hongbin

  From: Daneyon Hansen (danehans) [mailto:daneh...@cisco.com]
  Sent: November-25-15 11:10 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap



  From: 王华 mailto:wanghua.hum...@gmail.com>>
  Reply-To: "OpenStack Development Mail

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[Julien Danjou]

On Mon, Dec 07 2015, AFEK, Ifat (Ifat) wrote:

> Our goal is to get as much information as we can from various data 
> sources. If you connect Nagios to telemetry project, and we can get 
> nagios alarms directly from Aodh, it would be great. Is it something 
> that you planned on doing for Mitaka?

Unfortunately nobody planned to work on a Nagios -> Ceilometer/Gnocchi
connector. That maybe a good idea, and the fact that is not planned is
not necessarily a blocker. If someone wants to jump in…

> Our current use cases focus on giving value to the cloud admin. These 
> are mostly UI use cases; the admin will be able to:
>
> - view the topology of his environment, the relations between the 
> physical, virtual and applicative layer and the statuses all resources
> - view the alarms history (there is an existing blueprint for it[1])
> - view alarms about problems that Vitrage deduced could happen, even
> if no other OpenStack component reported these problems (yet)
> - view RCA information about the alarms

I find it odd to have UI use cases first, as their terribly large for a
MVP. Unless Vitrage already exists and you have all the code figured
out. :)

The way I see the big pictures, Vitrage should be done as some sort of
an engine on top of Ceilometer/Gnocchi/Aodh and leverage them to do RCA
analysis. So what's missing in those projects to make that happen should
be done, and Vitrage should start as a MVP; and then we can iterate,
both on Vitrage side and both on the telemetry projects.

I have the feeling that you're trying to bite a too large portion at
once and that you may crash because of that.

> In order to support these use cases, we will get input from various 
> data sources, process and evaluate it based on configurable templates, 
> trigger new alarms in Aodh and calculate RCA information. 
> On top of it, we will have Vitrage API to query the information and
> show it in horizon. 
> In case you haven't seen in yet, our high level architecture is on 
> Vitrage main page[2], and in the coming days we plan to document also 
> the lower level design.

I just looked at it, at it's very interesting. All the high level
functionalities make sense and provide values. But if you try to solve
them all 5 at once, I'm afraid you're going to either build a monster
(with a lot of overlap with other projects, hard to maintain, etc) or
just crash because you'll be blocked by all other OpenStack projects.
That's the big issue when starting to build a project on top of others
OpenStack bricks.

Overall I'm just saying that because it's still not clear to me which
part you're trying to solve in this thread and how we can help you. What
can we provide in our projects, that you miss, that could help you,
concretely? What feature we need to work on next?

It would be awesome to have _one_ use-case described end-to-end that you
would like to solve with Vitrage, leveraging various OpenStack projects,
that you cannot solve right now because of missing pieces. Then we could
start identifying these missing pieces and implement/fix them. :-)

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Hi Dmitry,

thank you for an update.
I personally think that 2 and 3 must be done in one blueprint as it related
to master node only and 2 shouldn't be a rocket science. What you mean
by "Non-root
accounts on slave nodes"? If we speak about disabling root for ssh,
creating new user and adding needed commands for him in sudoers - I believe
that it can be done in that blueprint too. If it is something much bigger -
it worth to be in separate blueprint.

On Fri, Dec 4, 2015 at 8:24 PM, Dmitry Nikishov 
wrote:

> Folks, there is another spec update, please take a look:
> https://review.openstack.org/#/c/243340
>
> I'm also considering splitting the blueprint/spec into smaller pieces:
>
> 1. Non-root accounts on slave nodes.
> 2. Non-root user account (fueladmin) on master node.
> 3. Running fuel services as non-superuser.
> 4. Running mcollective as non-root (tentative, still need a POC).
>
> Let me know what you think.
>
> On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov 
> wrote:
>
>> Folks, I have updated a spec, please review:
>> https://review.openstack.org/#/c/243340
>>
>> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov 
>> wrote:
>>
>>> Stanislaw,
>>>
>>> proposing patches could be a viable option long-term, however, by the
>>> time these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
>>>
>>> On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
 Dmitry, as we work on opensource - it would be really nice to propose
 patches to upstream for non-Fuel services. But if it is not an option -
 using puppet make sense to me.

 On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
 dnikis...@mirantis.com> wrote:

> Stanislaw,
>
> I want to clarify: there are 2 types of services, run on the Fuel node:
> - Those, which are a part of Fuel (astute, nailgun etc)
> - Those, which are not (e.g. atop)
>
> Capabilities for the former can easily be managed via post-install
> scripts, embedded in respective package spec file (since specs are a part
> of fuel-* repo). This is a very good idea.
> Capabilities for the latter will have to be taken care of via either
> a. some external utility (puppet)
> b. rebuilding respective package with updated spec
>
> I'd say that (a) is still more convinient.
>
> Another option would be to have a fine-grained control only on Fuel
> services and leave all the other at their defaults.
>
> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I just propose the way I think is right, because it's strange
>> enough - install package from *.deb file and then set any privileges to 
>> it
>> by third-party utility. Set permissions for app now mostly managed by
>> post-install scripts. Moreover - if it isn't - it should, cause if you 
>> set
>> capabilities by puppet there always will be a gap between installation 
>> and
>> setting permissions, so you will must bound package installation process
>> with setting permissions by puppet - other way you will have no way to 
>> use
>> your app.
>>
>> Setting setuid bits on apps is not a good idea - it is why linux
>> capabilities were introduced.
>>
>> On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <
>> dnikis...@mirantis.com> wrote:
>>
>>> Stanislaw,
>>>
>>> In my opinion the whole feature shouldn't be in the separate package
>>> simply because it will actually affect the code of many, if not all,
>>> components of Fuel.
>>>
>>> The only services whose capabilities will have to be managed by
>>> puppet are those, which are installed from upstream packages (e.g. 
>>> atop) --
>>> not built from fuel-* repos.
>>>
>>> Supervisord doesn't seem to use Linux capabilities, id does setuid
>>> instead:
>>> https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326
>>>
>>> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
 Dmitry, I mean whole feature.
 Btw, why do you want to grant capabilities via puppet? It should be
 done by post-install package section, I believe.

 Also I doesn't know if supervisord can bound process capabilities
 like systemd can - we could use this opportunity too.

 On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <
 dnikis...@mirantis.com> wrote:

> My main concern with using linux capabilities/acls on files is
> actually puppet support or, actually, the lack of it. ACLs are 
> possible
> AFAIK, but we'd need to write a custom type/provider for 
> capabilities. I
> suggest to wait with capabilities support till systemd support.
>
> On Tue, Nov 17, 2015 at 9:15 AM, Dmi

Re: [openstack-dev] [Fuel] Patch size limit

[Igor Kalnitsky]

Hey Andrii,

I'm totally agree with you about contribution guides, except one thing
- we need and should force users to split huge patches into set of
small ones. Mostly because it will simplify support and review of
patches. Previously we ignored this rule pretty often, and get a lot
of troubles due to buggy code.

Also, see some comments below.

> So, when an author of a patch gets -1 with the statement «split this
> code», I believe it is not constructive. At least you should roughly
> describe how you see it, how the patch could be split, you should be
> helpful to the author of a patch.

No one is suggesting to set -1 without leaving a comment how the patch
could be divided.


> If you are not sure how the improved code would look like, just let it go!

What if you're not sure how the improved code should look like, but
you definitely sure that it shouldn't look like proposed one? :)

I'd say it's a good reason to set -1 and start discussion. Not only
with author, but with other folks, since everyone in community is
responsible of code quality of the project.

- I

On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov  wrote:
> I believe this is against the code review guidelines.
>
> «Comments must be meaningful and should help an author to change the
> code the right way.» [1]
>
> If you get a comment that says «split this change into the smaller
> commit» I'm sorry, but it doesn't help at all.
>
> «Leave constructive comments
>
> Not everyone in the community is a native English speaker, so make
> sure your remarks are meaningful and helpful for the patch author to
> change his code, but also polite and respectful.
>
> The review is not really about the score. It's all about the
> comments. When you are reviewing code, always make sure that your
> comments are useful and helpful to the author of the patch. Try to
> avoid leaving comments just to show that you reviewed something if
> they don't really add anything meaningful» [2]
>
> So, when an author of a patch gets -1 with the statement «split this
> code», I believe it is not constructive. At least you should roughly
> describe how you see it, how the patch could be split, you should be
> helpful to the author of a patch. So, first of all, you need to review
> the patch! :)
>
> I want to emphasize this: «The review is not really about the
> score. It's all about the comments.»
>
> «In almost all cases, a negative review should be accompanied by clear
> instructions for the submitter how they might fix the patch.» [4]
>
> I believe that the statement "split this change into the smaller
> commit" is too generic, it is mostly the same as the "this patch needs
> further work". It doesn't bring any additional instructions how
> exactly a patch could be fixed.
>
> Please also take a loot at the following conversation from mailing
> list: [3].
>
> «It's not so easy to guess what you mean, and in case of a clumsy
> piece of code, not even that certain that better code can be used
> instead. So always provide an example of what you would rather want to
> see. So instead of pointing to indentation rules, just show properly
> indented code. Instead of talking about grammar or spelling, just type
> the corrected comment or docstring. Finally, instead of saying "use
> list comprehension here" or "don't use has_key", just type your
> proposal of how the code should look like. Then we have something
> concrete to talk about. Of course, you can also say why you think this
> is better, but an example is very important. If you are not sure how
> the improved code would look like, just let it go, chances are it
> would look even worse.» [3]
>
> So, please, bring something concrete to talk about. If you are not
> sure how the improved code would look like, just let it go!
>
> «The simplest way to talk about code is to just show the code. When you
> want the author to fix something, rewrite it in a different way,
> format the code differently, etc. -- it's best to just write in the
> comment how you want that code to look like. It's much faster than
> having the author guess what you meant in your descriptions, and also
> lets us learn much faster by seeing examples.» [2]
>
>
> [1]
> https://docs.google.com/document/d/1tyKhHQRQqTEW6tS7_LCajEpzqn55f-f5nDmtzIeJ2uY/edit
> [2] https://wiki.openstack.org/wiki/CodeReviewGuidelines
> [3]
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07831.html
> [4] http://docs.openstack.org/infra/manual/developers.html#peer-review
>
>
> Best regards,
> Andrey Tykhonov (tkhno)
>
>
> __
> OpenStack Development Mailing 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-r

Re: [openstack-dev] [Fuel] Patch size limit

[Sergii Golovatiuk]

Hi,

On Mon, Dec 7, 2015 at 2:28 AM, Andrey Tykhonov 
wrote:

> I believe this is against the code review guidelines.
>
> «Comments must be meaningful and should help an author to change the
> code the right way.» [1]
>

Could you provide a link that accessible by community? Thanks a lot in
advance.


>
> If you get a comment that says «split this change into the smaller
> commit» I'm sorry, but it doesn't help at all.
>
> «Leave constructive comments
>
> Not everyone in the community is a native English speaker, so make
> sure your remarks are meaningful and helpful for the patch author to
> change his code, but *also polite and respectful*.
>
> The review is not really about the score. It's all about the
> comments. When you are reviewing code, always make sure that your
> comments are useful and helpful to the author of the patch. Try to
> avoid leaving comments just to show that you reviewed something if
> they don't really add anything meaningful» [2]
>
> So, when an author of a patch gets -1 with the statement «split this
> code», I believe it is not constructive. At least you should roughly
> describe how you see it, how the patch could be split, you should be
> helpful to the author of a patch. So, first of all, you need to review
> the patch! :)
>
> I want to emphasize this: «
> *The review is not really about thescore. It's all about the comments.*»
>
> «In almost all cases, a negative review should be accompanied by
> *clearinstructions* for the submitter how they might fix the patch.» [4]
>
> I believe that the statement "split this change into the smaller
> commit" is too generic, it is mostly the same as the "this patch needs
> further work". It doesn't bring any additional instructions how
> exactly a patch could be fixed.
>
> Please also take a loot at the following conversation from mailing
> list: [3].
>
> «It's not so easy to guess what you mean, and in case of a clumsy
> piece of code, not even that certain that better code can be used
> instead. So always provide an example of what you would rather want to
> see. So instead of pointing to indentation rules, just show properly
> indented code. Instead of talking about grammar or spelling, just type
> the corrected comment or docstring. Finally, instead of saying "use
> list comprehension here" or "don't use has_key", just type your
> proposal of how the code should look like. Then we have something
> concrete to talk about. Of course, you can also say why you think this
> is better, but an example is very important. If you are not sure how
> the improved code would look like, just let it go, chances are it
> would look even worse.» [3]
>
> So, please, bring something concrete to talk about. If you are not
> sure how the improved code would look like, just let it go!
>
> «The simplest way to talk about code is to just show the code. When you
> want the author to fix something, rewrite it in a different way,
> format the code differently, etc. -- it's best to just write in the
> comment how you want that code to look like. It's much faster than
> having the author guess what you meant in your descriptions, and also
> lets us learn much faster by seeing examples.» [2]
>
>
> [1]
> https://docs.google.com/document/d/1tyKhHQRQqTEW6tS7_LCajEpzqn55f-f5nDmtzIeJ2uY/edit
> [2] https://wiki.openstack.org/wiki/CodeReviewGuidelines
> [3]
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07831.html
> [4] http://docs.openstack.org/infra/manual/developers.html#peer-review
>
>
> Best regards,
> Andrey Tykhonov (tkhno)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Patch size limit

[Stanislaw Bogatkin]

> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)

I believe you should ask other people if you are right, as set '-1' to code
that you
cannot improve is not the best option, so


> If you are not sure how the improved code would look like, just let it go!
is right


Also I think that set some strict boundaries, like 400 LOC per patch is
wrong. For example, if you
introduce new test fixture for fuel-library, it usually about 800+ LOC and
you can't split it
out, so we should either move such fixtures out of code or make an exeption
for such type of code.

On Mon, Dec 7, 2015 at 1:03 PM, Igor Kalnitsky 
wrote:

> Hey Andrii,
>
> I'm totally agree with you about contribution guides, except one thing
> - we need and should force users to split huge patches into set of
> small ones. Mostly because it will simplify support and review of
> patches. Previously we ignored this rule pretty often, and get a lot
> of troubles due to buggy code.
>
> Also, see some comments below.
>
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not constructive. At least you should roughly
> > describe how you see it, how the patch could be split, you should be
> > helpful to the author of a patch.
>
> No one is suggesting to set -1 without leaving a comment how the patch
> could be divided.
>
>
> > If you are not sure how the improved code would look like, just let it
> go!
>
> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)
>
> I'd say it's a good reason to set -1 and start discussion. Not only
> with author, but with other folks, since everyone in community is
> responsible of code quality of the project.
>
> - I
>
> On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov 
> wrote:
> > I believe this is against the code review guidelines.
> >
> > «Comments must be meaningful and should help an author to change the
> > code the right way.» [1]
> >
> > If you get a comment that says «split this change into the smaller
> > commit» I'm sorry, but it doesn't help at all.
> >
> > «Leave constructive comments
> >
> > Not everyone in the community is a native English speaker, so make
> > sure your remarks are meaningful and helpful for the patch author to
> > change his code, but also polite and respectful.
> >
> > The review is not really about the score. It's all about the
> > comments. When you are reviewing code, always make sure that your
> > comments are useful and helpful to the author of the patch. Try to
> > avoid leaving comments just to show that you reviewed something if
> > they don't really add anything meaningful» [2]
> >
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not constructive. At least you should roughly
> > describe how you see it, how the patch could be split, you should be
> > helpful to the author of a patch. So, first of all, you need to review
> > the patch! :)
> >
> > I want to emphasize this: «The review is not really about the
> > score. It's all about the comments.»
> >
> > «In almost all cases, a negative review should be accompanied by clear
> > instructions for the submitter how they might fix the patch.» [4]
> >
> > I believe that the statement "split this change into the smaller
> > commit" is too generic, it is mostly the same as the "this patch needs
> > further work". It doesn't bring any additional instructions how
> > exactly a patch could be fixed.
> >
> > Please also take a loot at the following conversation from mailing
> > list: [3].
> >
> > «It's not so easy to guess what you mean, and in case of a clumsy
> > piece of code, not even that certain that better code can be used
> > instead. So always provide an example of what you would rather want to
> > see. So instead of pointing to indentation rules, just show properly
> > indented code. Instead of talking about grammar or spelling, just type
> > the corrected comment or docstring. Finally, instead of saying "use
> > list comprehension here" or "don't use has_key", just type your
> > proposal of how the code should look like. Then we have something
> > concrete to talk about. Of course, you can also say why you think this
> > is better, but an example is very important. If you are not sure how
> > the improved code would look like, just let it go, chances are it
> > would look even worse.» [3]
> >
> > So, please, bring something concrete to talk about. If you are not
> > sure how the improved code would look like, just let it go!
> >
> > «The simplest way to talk about code is to just show the code. When you
> > want the author to fix something, rewrite it in a different way,
> > format the code differently, etc. -- it's best to just write in the
> > comment how you want that code to look like. It's much faster than
> > having the author guess what you meant in your descripti

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Dina Belova]

Ok, so due to the responses I propose to finalise this decision and move
the meeting to *16:00 UTC (Tuesdays)*.
So tomorrow please join me *on #openstack-performance at 16:00 UTC.*

Cheers, Dina

P.S.
Ryan, I'm suggesting you to come as usually at 15:00, I'll be online -
let's prepare possible questions you're interested in to be covered during
the meeting time. I'll be happy to make everything possible for you to
participate at least in this way..

On Sat, Dec 5, 2015 at 2:12 AM, Clint Byrum  wrote:

> Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
> > Dear performance folks,
> >
> > There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> > ) to
> > 16:00 UTC (also Tuesdays
> > ) to
> > make them more comfortable for US guys.
> >
> > Please leave your +1 / -1 here in the email thread.
> >
> > Btw +1 from me :)
>
> +1, this makes it actually possible for me to participate. :)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Fuel] FFE for Ubuntu bootstrap

[Sergii Golovatiuk]

+1 for FFE toll Tuesday 8th of December.

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

On Fri, Dec 4, 2015 at 4:43 PM, Dmitry Klenov  wrote:

> Hi Mike and Igor,
>
> Thank you for the opinions.
>
> We already talked to Matt and he is fine with Fuel Menu commit. We will
> target the changes for Tuesday and will work with reviewers and Mos-Linux
> team to have blocker bug resolved and commits merged.
>
> Thanks,
> Dmitry.
>
> On Fri, Dec 4, 2015 at 2:04 PM, Igor Kalnitsky 
> wrote:
>
>> Hey Dmitry,
>>
>> I'm ok with FFE till Tuesday. Moreover, it makes sense to do so in
>> order to reduce affection on CentOS 7 patches.
>>
>> - Igor
>>
>> On Thu, Dec 3, 2015 at 8:58 PM, Dmitry Klenov 
>> wrote:
>> > Hi folks,
>> >
>> > Let me clarify the situation with Ubuntu bootstrap feature.
>> >
>> > First of all, I would like to highlight that all functional commits for
>> this
>> > feature were merged. This means that starting from yesterday everyone
>> has an
>> > ability to switch to Ubuntu-based bootstrap manually and start using
>> it. So
>> > I do not see the risk in loosing testing cycles in the community.
>> >
>> > The item which brought concerns on today status meeting was the
>> enablement
>> > of the feature by default. To do it, 2 patches have to be merged
>> together:
>> > * https://review.openstack.org/#/c/250662/ - main switch.
>> > * https://review.openstack.org/#/c/251908/ - compatibility commit to QA
>> > suite to comply with new bootstrap config format.
>> >
>> > I would like to raise the question if we can have a feature freeze
>> exception
>> > for these 2 patches?
>> >
>> > There are a couple of reasons why I consider it safer to merge these
>> patches
>> > several days later:
>> > * There is a bug caught today which will block the tests to pass if we
>> > switch to Ubuntu bootstrap by default:
>> > https://bugs.launchpad.net/fuel/+bug/1522406
>> > * There were concerns that a lot of FF commit merges can bring
>> instability
>> > to QA suite. So it might be reasonable not to bring one more variable
>> right
>> > now and to enable ubuntu bootstrap by default when all automated tests
>> are
>> > stabilized.
>> >
>> > I would like to ask engineering and QA leads to express their ideas on
>> this.
>> >
>> > Thanks,
>> > Dmitry.
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] CentOS7: merge freeze is lifted

[Andrew Maksimov]

Hi All,

Centos7 patches were successfully integrated into Fuel 8.0, so we are
removing merge freeze from all repositories according to our plan [1].
Please continue merge as usual.

[1] -
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html

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

Re: [openstack-dev] [Fuel][library] CI gate for regressions detection in deployment data

[Bogdan Dobrelya]

On 02.12.2015 17:03, Bogdan Dobrelya wrote:
> On 01.12.2015 11:28, Aleksandr Didenko wrote:
>> Hi,
>>
>>> pregenerated catalogs for the Noop tests to become the very first
>>> committed state in the data regression process has to be put in the
>>> *separate repo*
>>
>> +1 to that, we can put this new repo into .fixtures.yml
>>
>>> note, we could as well move the tests/noop/astute.yaml/ there
>>
>> +1 here too, astute.yaml files are basically configuration fixtures, we
>> can put them into .fixtures.yml as well

Folks, the patch to create the fuel-noop-fixtures [0] is in trouble.
I'm not sure I've answered Andreas's questions correct:

- Would it be OK to keep Noop tests fixtures for fuel-library as a
separate Fuel-related repo but *not* as a part of the Fuel project?

- Should we require the contribution license agreement for fixtures
which are only be used by tests?

[0] https://review.openstack.org/252992

> 
> I found the better -and easier for patch authors- way to use the data
> regression checks. Originally suggested workflow was:
> 
> 1.
> "The check should be done for every modular component (aka deployment
> task). Data generated in the noop catalog run for all classes and
> defines of a given deployment task should be verified against its
> "acknowledged" (committed) state."
> 
> This part remains the same with the only comment that the astute.yaml
> fixtures of deployment cases should be fetched from the
> fuel-noop-fixtures repo. And the committed state for generated catalogs
> should be
> stored there as well.
> 
> 2.
> "And fail the test gate, if changes has been found, like new parameter
> with a defined value, removed a parameter, changed a parameter's value."
> 
> This should be changed as following:
> - the data checks gate should be just a non voting helper for reviewers
> and patch authors. The only its task would be to show inducted data
> changes in a pretty and fast view to help accept/update/reject a patch
> on review.
> - the data checks gate job should fetch the committed data state from
> the fuel-noop-fixtures repo and run regressions check with the patch
> under review checked out on fuel-library repo.
> - the Noop tests gate should be changed to fetch the astute.yaml
> fixtures from the fuel-noop-fixtures repo in order to run noop tests as
> usual.
> 
> 3.
> "In order to remove a regression, a patch author will have to add (and
> reviewers should acknowledge) detected changes in the committed state of
> the deployment data. This may be done manually, with a tool like [3] or
> by a pre-commit hook, or even at the CI side!"
> 
> Instead, the patch authors should do nothing additionally. Once accepted
> with wf+1, the patch on reivew should be merged with a pre-commit zuul
> hook (is it possible?). The hook should just regenerate catalogs with
> the changes introduced by the patch and update the committed state of
> data in the fuel-noop-fixtures repo. After that, the patch may be safely
> merged to the fuel-library and everything will be up to date with the
> committed data state.
> 
> 4.
> "The regression check should show the diff between committed state and a
> new state proposed in a patch. Changed state should be *reviewed* and
> accepted with a patch, to became a committed one. So the deployment data
> will evolve with *only* approved changes. And those changes would be
> very easy to be discovered for each patch under review process!"
> 
> So this part would work even better now, with no additional actions
> required from the review process sides.
> 
>>
>> Regards,
>> Alex
>>
>>
>> On Mon, Nov 30, 2015 at 1:03 PM, Bogdan Dobrelya > > wrote:
>>
>> On 20.11.2015 17:41, Bogdan Dobrelya wrote:
>> >> Hi,
>> >>
>> >> let me try to rephrase this a bit and Bogdan will correct me if
>> I'm wrong
>> >> or missing something.
>> >>
>> >> We have a set of top-scope manifests (called Fuel puppet tasks)
>> that we use
>> >> for OpenStack deployment. We execute those tasks with "puppet
>> apply". Each
>> >> task supposed to bring target system into some desired state, so
>> puppet
>> >> compiles a catalog and applies it. So basically, puppet catalog =
>> desired
>> >> system state.
>> >>
>> >> So we can compile* catalogs for all top-scope manifests in master
>> branch
>> >> and store those compiled* catalogs in fuel-library repo. Then for
>> each
>> >> proposed patch CI will compare new catalogs with stored ones and
>> print out
>> >> the difference if any. This will pretty much show what is going to be
>> >> changed in system configuration by proposed patch.
>> >>
>> >> We were discussing such checks before several times, iirc, but we
>> did not
>> >> have right tools to implement such thing before. Well, now we do
>> :) I think
>> >> it could be quite useful even in non-voting mode.
>> >>
>> >> * By saying compiled catalogs I

Re: [openstack-dev] [Fuel] Patch size limit

[Andrey Tykhonov]

On 7 December 2015 at 12:20, Sergii Golovatiuk 
wrote:

> Hi,
>
> On Mon, Dec 7, 2015 at 2:28 AM, Andrey Tykhonov 
> wrote:
>
>> I believe this is against the code review guidelines.
>>
>> «Comments must be meaningful and should help an author to change the
>> code the right way.» [1]
>>
>
> Could you provide a link that accessible by community? Thanks a lot in
> advance.
>


Sure! I'm sorry for this link.

BTW, if you even aren't able to open this link, you don't miss
anything because mostly the same is described in the code review
guidelines.


Thank you!


>
>
>>
>> If you get a comment that says «split this change into the smaller
>> commit» I'm sorry, but it doesn't help at all.
>>
>> «Leave constructive comments
>>
>> Not everyone in the community is a native English speaker, so make
>> sure your remarks are meaningful and helpful for the patch author to
>> change his code, but *also polite and respectful*.
>>
>> The review is not really about the score. It's all about the
>> comments. When you are reviewing code, always make sure that your
>> comments are useful and helpful to the author of the patch. Try to
>> avoid leaving comments just to show that you reviewed something if
>> they don't really add anything meaningful» [2]
>>
>> So, when an author of a patch gets -1 with the statement «split this
>> code», I believe it is not constructive. At least you should roughly
>> describe how you see it, how the patch could be split, you should be
>> helpful to the author of a patch. So, first of all, you need to review
>> the patch! :)
>>
>> I want to emphasize this: «
>> *The review is not really about thescore. It's all about the comments.*»
>>
>> «In almost all cases, a negative review should be accompanied by
>> *clearinstructions* for the submitter how they might fix the patch.» [4]
>>
>> I believe that the statement "split this change into the smaller
>> commit" is too generic, it is mostly the same as the "this patch needs
>> further work". It doesn't bring any additional instructions how
>> exactly a patch could be fixed.
>>
>> Please also take a loot at the following conversation from mailing
>> list: [3].
>>
>> «It's not so easy to guess what you mean, and in case of a clumsy
>> piece of code, not even that certain that better code can be used
>> instead. So always provide an example of what you would rather want to
>> see. So instead of pointing to indentation rules, just show properly
>> indented code. Instead of talking about grammar or spelling, just type
>> the corrected comment or docstring. Finally, instead of saying "use
>> list comprehension here" or "don't use has_key", just type your
>> proposal of how the code should look like. Then we have something
>> concrete to talk about. Of course, you can also say why you think this
>> is better, but an example is very important. If you are not sure how
>> the improved code would look like, just let it go, chances are it
>> would look even worse.» [3]
>>
>> So, please, bring something concrete to talk about. If you are not
>> sure how the improved code would look like, just let it go!
>>
>> «The simplest way to talk about code is to just show the code. When you
>> want the author to fix something, rewrite it in a different way,
>> format the code differently, etc. -- it's best to just write in the
>> comment how you want that code to look like. It's much faster than
>> having the author guess what you meant in your descriptions, and also
>> lets us learn much faster by seeing examples.» [2]
>>
>>
>> [1]
>> https://docs.google.com/document/d/1tyKhHQRQqTEW6tS7_LCajEpzqn55f-f5nDmtzIeJ2uY/edit
>> [2] https://wiki.openstack.org/wiki/CodeReviewGuidelines
>> [3]
>> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07831.html
>> [4] http://docs.openstack.org/infra/manual/developers.html#peer-review
>>
>>
>> Best regards,
>> Andrey Tykhonov (tkhno)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Sylvain Bauza]

Le 07/12/2015 11:27, Dina Belova a écrit :
Ok, so due to the responses I propose to finalise this decision and 
move the meeting to *16:00 UTC (Tuesdays)*.

So tomorrow please join me *on #openstack-performance at 16:00 UTC.*



Why are you not using the meeting channels?
You should also provide a YAML file here 
http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/


-Sylvain


Cheers, Dina

P.S.
Ryan, I'm suggesting you to come as usually at 15:00, I'll be online - 
let's prepare possible questions you're interested in to be covered 
during the meeting time. I'll be happy to make everything possible for 
you to participate at least in this way..


On Sat, Dec 5, 2015 at 2:12 AM, Clint Byrum > wrote:


Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
> Dear performance folks,
>
> There is a suggestion to move our meeting time from 15:00 UTC
(Tuesdays
>
)
to
> 16:00 UTC (also Tuesdays
>
)
to
> make them more comfortable for US guys.
>
> Please leave your +1 / -1 here in the email thread.
>
> Btw +1 from me :)

+1, this makes it actually possible for me to participate. :)

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.



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


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

Re: [openstack-dev] [Fuel] Patch size limit

[Roman Prykhodchenko]

Maciej, thanks for bringing this topic up for the discussion!

I absolutely agree with the idea that at this point we have a problem with 
patch size. Patches that are too big usually have two major issues: they either 
don’t get reviewed for a very long time or get random +1s from people who don’t 
even bother reading all the changes there.

Splitting a patch when it’s already published may be pretty problematic, so we 
should think about granularity of every feature on the design stage. Only in 
that way we will be able to submit small patches w/o making compromises on test 
coverage, stability or any other important aspect of the code quality.

Folks proposed two different solutions here:
  1. Set a CI job that puts a -1 to every patch that’s bigger than a certain 
limit.
  2. Make reviewers responsible for -1ing a patch.

Most of the patches that are bigger than 500 LOC can be split. However, there 
is a lot of corner cases we have to carry about, if we are going to put a -1 to 
all of them automatically. In my opinion we should not do that. Instead, we can 
send warning emails to core teams if this kind of patch set is submitted. Then 
a core team may easily analyze whether this patch can be split and propose a 
meaningful way to do that.

Huge patches cause a different story — they are incredibly hard for making a 
good review, merging or reverting them can lead to a major regression in a lot 
of places, they cause conflicts for a lot of other patches and so on. A huge 
patch ALWAYS means exclusively one of the following:
  1. It can be split
  2. The design of the feature is completely wrong.

We need to set a treshold for a huge patch and block all patches that exceed it 
by putting -2 scores.

Summary:

- Let’s set two thresholds — one for to big and one for huge patches.
- Let’s create a job that will warn an appropriate core team if a too big patch 
is submitted and block huge patches.


- romcheg



> 7 груд. 2015 р. о 11:23 Stanislaw Bogatkin  
> написав(ла):
> 
> > What if you're not sure how the improved code should look like, but
> > you definitely sure that it shouldn't look like proposed one? :)
> 
> I believe you should ask other people if you are right, as set '-1' to code 
> that you
> cannot improve is not the best option, so
> 
> 
> > If you are not sure how the improved code would look like, just let it go!
> is right
> 
> 
> Also I think that set some strict boundaries, like 400 LOC per patch is 
> wrong. For example, if you
> introduce new test fixture for fuel-library, it usually about 800+ LOC and 
> you can't split it
> out, so we should either move such fixtures out of code or make an exeption 
> for such type of code.
> 
> On Mon, Dec 7, 2015 at 1:03 PM, Igor Kalnitsky  > wrote:
> Hey Andrii,
> 
> I'm totally agree with you about contribution guides, except one thing
> - we need and should force users to split huge patches into set of
> small ones. Mostly because it will simplify support and review of
> patches. Previously we ignored this rule pretty often, and get a lot
> of troubles due to buggy code.
> 
> Also, see some comments below.
> 
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not constructive. At least you should roughly
> > describe how you see it, how the patch could be split, you should be
> > helpful to the author of a patch.
> 
> No one is suggesting to set -1 without leaving a comment how the patch
> could be divided.
> 
> 
> > If you are not sure how the improved code would look like, just let it go!
> 
> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)
> 
> I'd say it's a good reason to set -1 and start discussion. Not only
> with author, but with other folks, since everyone in community is
> responsible of code quality of the project.
> 
> - I
> 
> On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov  > wrote:
> > I believe this is against the code review guidelines.
> >
> > «Comments must be meaningful and should help an author to change the
> > code the right way.» [1]
> >
> > If you get a comment that says «split this change into the smaller
> > commit» I'm sorry, but it doesn't help at all.
> >
> > «Leave constructive comments
> >
> > Not everyone in the community is a native English speaker, so make
> > sure your remarks are meaningful and helpful for the patch author to
> > change his code, but also polite and respectful.
> >
> > The review is not really about the score. It's all about the
> > comments. When you are reviewing code, always make sure that your
> > comments are useful and helpful to the author of the patch. Try to
> > avoid leaving comments just to show that you reviewed something if
> > they don't really add anything meaningful» [2]
> >
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not co

Re: [openstack-dev] [Fuel] Patch size limit

[Roman Prykhodchenko]

Following up on my previous email:

Every blueprint specification has a Work items section. That section should 
describe granular work items, not just things in general. We should encourage 
components leads to put their attention to this aspect.



> 7 груд. 2015 р. о 12:23 Roman Prykhodchenko  написав(ла):
> 
> Maciej, thanks for bringing this topic up for the discussion!
> 
> I absolutely agree with the idea that at this point we have a problem with 
> patch size. Patches that are too big usually have two major issues: they 
> either don’t get reviewed for a very long time or get random +1s from people 
> who don’t even bother reading all the changes there.
> 
> Splitting a patch when it’s already published may be pretty problematic, so 
> we should think about granularity of every feature on the design stage. Only 
> in that way we will be able to submit small patches w/o making compromises on 
> test coverage, stability or any other important aspect of the code quality.
> 
> Folks proposed two different solutions here:
>   1. Set a CI job that puts a -1 to every patch that’s bigger than a certain 
> limit.
>   2. Make reviewers responsible for -1ing a patch.
> 
> Most of the patches that are bigger than 500 LOC can be split. However, there 
> is a lot of corner cases we have to carry about, if we are going to put a -1 
> to all of them automatically. In my opinion we should not do that. Instead, 
> we can send warning emails to core teams if this kind of patch set is 
> submitted. Then a core team may easily analyze whether this patch can be 
> split and propose a meaningful way to do that.
> 
> Huge patches cause a different story — they are incredibly hard for making a 
> good review, merging or reverting them can lead to a major regression in a 
> lot of places, they cause conflicts for a lot of other patches and so on. A 
> huge patch ALWAYS means exclusively one of the following:
>   1. It can be split
>   2. The design of the feature is completely wrong.
> 
> We need to set a treshold for a huge patch and block all patches that exceed 
> it by putting -2 scores.
> 
> Summary:
> 
> - Let’s set two thresholds — one for to big and one for huge patches.
> - Let’s create a job that will warn an appropriate core team if a too big 
> patch is submitted and block huge patches.
> 
> 
> - romcheg
> 
> 
> 
>> 7 груд. 2015 р. о 11:23 Stanislaw Bogatkin > > написав(ла):
>> 
>> > What if you're not sure how the improved code should look like, but
>> > you definitely sure that it shouldn't look like proposed one? :)
>> 
>> I believe you should ask other people if you are right, as set '-1' to code 
>> that you
>> cannot improve is not the best option, so
>> 
>> 
>> > If you are not sure how the improved code would look like, just let it go!
>> is right
>> 
>> 
>> Also I think that set some strict boundaries, like 400 LOC per patch is 
>> wrong. For example, if you
>> introduce new test fixture for fuel-library, it usually about 800+ LOC and 
>> you can't split it
>> out, so we should either move such fixtures out of code or make an exeption 
>> for such type of code.
>> 
>> On Mon, Dec 7, 2015 at 1:03 PM, Igor Kalnitsky > > wrote:
>> Hey Andrii,
>> 
>> I'm totally agree with you about contribution guides, except one thing
>> - we need and should force users to split huge patches into set of
>> small ones. Mostly because it will simplify support and review of
>> patches. Previously we ignored this rule pretty often, and get a lot
>> of troubles due to buggy code.
>> 
>> Also, see some comments below.
>> 
>> > So, when an author of a patch gets -1 with the statement «split this
>> > code», I believe it is not constructive. At least you should roughly
>> > describe how you see it, how the patch could be split, you should be
>> > helpful to the author of a patch.
>> 
>> No one is suggesting to set -1 without leaving a comment how the patch
>> could be divided.
>> 
>> 
>> > If you are not sure how the improved code would look like, just let it go!
>> 
>> What if you're not sure how the improved code should look like, but
>> you definitely sure that it shouldn't look like proposed one? :)
>> 
>> I'd say it's a good reason to set -1 and start discussion. Not only
>> with author, but with other folks, since everyone in community is
>> responsible of code quality of the project.
>> 
>> - I
>> 
>> On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov > > wrote:
>> > I believe this is against the code review guidelines.
>> >
>> > «Comments must be meaningful and should help an author to change the
>> > code the right way.» [1]
>> >
>> > If you get a comment that says «split this change into the smaller
>> > commit» I'm sorry, but it doesn't help at all.
>> >
>> > «Leave constructive comments
>> >
>> > Not everyone in the community is a native English speaker, so make
>> > sure your remarks are meaningful and helpful for the patch aut

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

[Neil Jerram]

On 04/12/15 19:24, Henry Gessau wrote:
> Sean M. Collins  wrote:
>> I've noticed that a lot of features are now being documented as RSTs
>> inside of devref. Like the following:
>>
>> https://review.openstack.org/#/c/251859/
>>
>> But there are lots already present. Can someone point out to me what the
>> criteria is for these documents? I am a little confused about the
>> relationship between neutron-specs, RFE bugs, and some features being
>> documented in devref. Especially when a review includes the actual code,
>> then a new RST file in devref - wasn't that what specs were for?
> Here is how I would like to see things ending up:
>
> 1. RFE: "I want X"
> 2. Spec: "I plan to implement X like this"
> 3. devref: "How X is implemented and how to extend it"
> 4. OS docs: "API and guide for using X"

> Once X is implemented I don't want to have to go to 1 or 2 to find information
> on it. The devref may have a lot of content from the spec, but the spec is not
> maintained and the implementation may differ in some ways. The devref should
> be kept current with refactorings, etc. of the implementation.
>

FWIW, that's exactly how I'd see things too.  It may be well that some
of a spec's text is roughly suitable for later moving to a devref or OS
doc, but even so it should be re-reviewed and edited for the new
context, and for any details that changed during implementation.

Regards,
Neil


__
OpenStack Development Mailing 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] [client][all][neutron] client option removal policy

[Akihiro Motoki]

Hi,

neutronclient is now dropping XML support and as a result
"--request-format" option is no longer needed as JSON is the only format now.

What is the recommended way for options no longer needed?
Does bumping major version of CLI allow us to drop an option without
deprecation?

- Deprecate such option.
  The option still exists with only one available choiceuntil the
option is deleted.

- Drop it without deprecation.
  This breaks users who uses "--requiest-format json", but 'json' is the default
  value and most users do not specify the option.

Thanks,
Akihiro

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

[openstack-dev] [nova][glance] Nova using service tokens with protected properties in Glance

[Bunting, Niall]

Hi,

There is the following spec for review:
https://review.openstack.org/#/c/249950/ for allowing the modification
of protected properties with service tokens in Glance.

John & Stuart suggest using service tokens for the following Nova spec:
https://review.openstack.org/#/c/206431/ (Inheritable admin image
properties).

It would be great to see some Nova input on the Glance spec taking into
consideration the proposed Nova spec.

Thanks,
Niall Bunting

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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

On 12/07/2015 10:48 AM, Thierry Carrez wrote:

Dmitry Tantsur wrote:


2015-12-04 18:26 GMT+01:00 Doug Hellmann mailto:d...@doughellmann.com>>:





 Please don't delete anything older than Mitaka.


Do you have any hints how to not confuse users in this case?


I think what Doug means is you should not delete existing closed
milestones like:
https://launchpad.net/ironic/kilo/2015.1.0
or:
https://launchpad.net/ironic/liberty/4.2.0
since we use the Launchpad pages there as the list of features and bugs
fixed for those pre-reno releases.

Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?



I wonder how to avoid giving impression that development has stopped on 
4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as 
we no longer push tarballs to launchpad.


__
OpenStack Development Mailing 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] [client][all][neutron] client option removal policy

[Salvatore Orlando]

The Neutron API dropped XML support quite some time ago.
Therefore specifying --request-format xml already produces an error.
Even if  this parameter is already vestigial and should be abruptly
removed. We don't know whether anyone is using it. For instance one could
have a set of scripts that explicitly use it just to make sure it never
switched without knowing to XML!

Deprecation first is therefore, in my opinion, always the recommended path.

Salvatore

On 7 December 2015 at 12:58, Akihiro Motoki  wrote:

> Hi,
>
> neutronclient is now dropping XML support and as a result
> "--request-format" option is no longer needed as JSON is the only format
> now.
>
> What is the recommended way for options no longer needed?
> Does bumping major version of CLI allow us to drop an option without
> deprecation?
>
> - Deprecate such option.
>   The option still exists with only one available choiceuntil the
> option is deleted.
>
> - Drop it without deprecation.
>   This breaks users who uses "--requiest-format json", but 'json' is the
> default
>   value and most users do not specify the option.
>
> Thanks,
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Summary of In-Progress TripleO Workflow and REST API Development

[Dmitry Tantsur]

On 12/07/2015 04:33 AM, Tzu-Mainn Chen wrote:



On 04/12/15 23:04, Dmitry Tantsur wrote:

On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote:






5. In-Progress Development

The initial spec for the tripleo-common library has already
been approved, and
various people have been pushing work forward.  Here's a
summary:

* Move shared business logic out of CLI
* https://review.openstack.org/249134 - simple
validations (WIP)


When is this going to be finished? It's going to get me a huge
merge conflict in https://review.openstack.org/#/c/250405/ (and
make it impossible to backport to liberty btw).

This plan would be fine if Mitaka development was the only
consideration but I hope that it can be adapted a little bit to take
into account the Liberty branches, and the significant backports
that will be happening there. The rdomanager-plugin->tripleoclient
transition made backports painful, and having moved on for that it
would be ideal if we didn't create the same situation again.

What I would propose is the following:
- the tripleo_common repo is renamed to tripleo and consumed by Mitaka
- the tripleo_common repo continues to exist in Liberty
- the change to rename the package tripleo_common to tripleo occurs
on the tripleo repo in the master branch using oslo-style wildcard
imports[1], and initially no deprecation message
- this change is backported to the tripleo_common repo on the
stable/liberty branch


Heya - apologies for the bit of churn here.  I re-visited the
repo-renaming issue in IRC, and it sounds like
the vast majority of people are actually in favor of putting the
relevant library and API code in the
tripleo-common repository, and revisiting the creation of a tripleo
repository later, once code has had a
chance to settle.  I personally like this idea, as it reduces some
disruptive activity at a time when we're trying
to add quite a bit of new code.

I double-checked with the people who originally raised objections to the
idea of putting API code into
tripleo-common.  One said that his objection had to do with package
naming, and he removed his objection
once it was realized that the package name could be independent of the
repo name.  The other clarified his
objection as simply a consistency issue that he thought was okay to
resolve until after the API code settled a
bit.

So: I'm putting the idea of *not* creating a tripleo repo just quite yet
out there on the mailing list, and I'm
hopeful we can come to agreement in Tuesday's tripleo weekly IRC
meeting.  That would resolve a lot of the
concerns mentioned here, correct?


It does not seem to resolve mine concern, though. I'm still wondering 
where should I continue the major profiles refactoring. If it moves to 
triple-common/tripleo (whatever the name), how do I backport it?





Mainn


Once this is in place, stable/liberty tripleoclient can gradually
move from the tripleo_common to the tripleo package, and parts of
then tripleoclient -> tripleo_common business logic move can also be
backported where appropriate.

I'm planning on adding some liberty backportable commands as part of
blueprint tripleo-manage-software-deployments [2] and this approach
would greatly ease the backport process, and allow the business
logic to start in the tripleo repo.

* https://review.openstack.org/228991 - deployment code
(ready for review)

* Additional TripleO business logic
* rename tripleo-common repo to tripleo
  * https://review.openstack.org/#/c/249521/ (ready for
review)
  * https://review.openstack.org/#/c/249524/ (ready for
review)
  * https://review.openstack.org/#/c/247834/ (ready for
review)

(here is my review comment on this change)

I'd like to propose that we have a period where the tripleo_common
package continues to be usable without a deprecation message.

Rather than using deprecated subclasses, can we just do oslo-style
wildcard imports [1] for this package transition?

If we did that then the test files could just be moved to tripleo,
rather than duplicating them.

What I am hoping is that this change can be backported to
stable/liberty of tripleo_co mmon so that stable/liberty
tripleoclient can gradually transition over, and the work to move
business logic out of tripleoclient can also have targeted backports
to liberty tripleo_common/tripleoclient.


* https://review.openstack.org/#/c/242439 - capabilities
map (ready for review)
* https://review.openstack.org/#/c/227297/ - base
tripleo library code (ready for 

Re: [openstack-dev] [client][all][neutron] client option removal policy

[Neil Jerram]

On 07/12/15 12:01, Akihiro Motoki wrote:
> Hi,
>
> neutronclient is now dropping XML support and as a result
> "--request-format" option is no longer needed as JSON is the only format now.
>
> What is the recommended way for options no longer needed?
> Does bumping major version of CLI allow us to drop an option without
> deprecation?
>
> - Deprecate such option.
>   The option still exists with only one available choiceuntil the
> option is deleted.
>
> - Drop it without deprecation.
>   This breaks users who uses "--requiest-format json", but 'json' is the 
> default
>   value and most users do not specify the option.

I'd say it depends on how the deprecation of '--request-format xml' was
announced.  If it said

"XML format is deprecated and will be removed in a future release.  The
only supported format will then be JSON, and so the --request-format
option will also be removed"

then the option can clearly be removed now.

How was it announced?  If I look at
http://docs.openstack.org/cli-reference/content/neutronclient_commands.html,
I see many occurrences of

*--request-format {json,xml}*

The XML or JSON request format.

**

without anything to say that XML is deprecated.  And I see many other
things in the same page that _are_ marked as "DEPRECATED!"  So, if I was
reading this documentation, I would not know that XML format is deprecated.

Regards,
Neil


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

Re: [openstack-dev] [TripleO] workflow

[Dmitry Tantsur]

On 12/06/2015 05:33 PM, John Trowbridge wrote:



On 12/03/2015 03:47 PM, Dan Prince wrote:

On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:

On 23 November 2015 at 14:37, Dan Prince  wrote:

There are lots of references to "workflow" within TripleO
conversations
these days. We are at (or near) the limit of what we can do within
Heat
with regards to upgrades. We've got a new TripleO API in the works
(a
new version of Tuskar basically) that is specifically meant to
encapsulates business logic workflow around deployment. And, Lots
of
interest in using Ansible for this and that.

So... Last week I spent a bit of time tinkering with the Mistral
workflow service that already exists in OpenStack and after a few
patches got it integrated into my undercloud:

https://etherpad.openstack.org/p/tripleo-undercloud-workflow

One could imagine us coming up with a set of useful TripleO
workflows
(something like this):

  tripleo.deploy 
  tripleo.update 
  tripleo.run_ad_hoc_whatever_on_specific_roles <>

Since Mistral (the OpenStack workflow service) can already interact
w/
keystone and has a good many hooks to interact with core OpenStack
services like Swift, Heat, and Nova we might get some traction very
quickly here. Perhaps we add some new Mistral Ironic actions? Or
imagine smaller more focused Heat configuration stacks that we
drive
via Mistral? Or perhaps we tie in Zaqar (which already has some
integration into os-collect-config) to run ad-hoc deployment
snippets
on specific roles in an organized fashion?  Or wrapping mistral w/
tripleoclient to allow users to more easily call TripleO specific
workflows (enhancing the user feedback like we do with our
heatclient
wrapping already)?

Where all this might lead... I'm not sure. But I feel like we might
benefit by adding a few extra options to our OpenStack deployment
tool
chain.

I think this sounds promising. Lots of the code in the CLI is about
managing workflows. For example when doing introspection we change
the node state, poll for the result, start introspection, poll for
the result, change the node state back and poll for the result. If
mistral can help here I expect it could give us a much more robust
solution.


Hows this look:

https://github.com/dprince/tripleo-mistral-
workflows/blob/master/tripleo/baremetal.yaml



This is a really good starter example because the bulk inspection
command is particularly problematic. I like this a lot. One really nice
thing here is that we get a REST API for free by using Mistral.


Yeah, looks really good, except for 
https://github.com/dprince/tripleo-mistral-workflows/blob/master/tripleo/baremetal.yaml#L35-L39 
still talks about introspecting nodes in AVAILABLE state, which must be 
killed with fire. We should use ENROLL state when importing nodes 
instead and require a user to explicitly move nodes out of AVAILABLE 
state, if they want them to be introspected.







  Dan

___
___
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
bscribe
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:unsubs
cribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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



__
OpenStack Development Mailing 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] [puppet] weekly meeting #62

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151208

Thanks,
-- 
Emilien Macchi



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

[openstack-dev] [heat] Rico Lin for heat-core

[Sergey Kraynev]

Hi all.

I'd like to nominate Rico Lin for heat-core. He did awesome job with
providing useful and valuable reviews. Also his contribution is really high
[1] .

[1] http://stackalytics.com/report/contribution/heat-group/60

Heat core-team, please vote with:
 +1 - if you agree
  -1 - if you disagree

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

Re: [openstack-dev] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Thomas Goirand]

On 12/04/2015 03:23 PM, Anne Gentle wrote:
> 
> 
> On Fri, Dec 4, 2015 at 8:09 AM, Thomas Goirand  > wrote:
> 
> Hi,
> 
> I've investigated a bit the openstackdocstheme, and tried to remove some
> of the (numerous) javascript with external references. And it's *very*
> ugly: it's full of google stuff, random CDN and so on.
> 
> 
> I absolutely want to address these concerns. 

Hi,

Thanks for replying.

Let me start by this. In Debian, I'm adding this patch:

http://anonscm.debian.org/cgit/openstack/python-openstackdocstheme.git/tree/debian/patches/patch-out-external-references.patch

Now, let me explain why.

> Let's start with making sure I understand the concerns so we can start
> tracking the work requirements with bugs.
> 
> 1. Google stuff, considered non-free. Can you list specifics? Fonts and
> analytics js for starters, let me know if there are others?

It's not only about non-freeness, it's also about the fact that I don't
want Google to know when I'm browsing my local hard drive HTML, which it
would when browsing any OpenStack docs generated by OpenStack packages
in Debian, without the Debian patch to openstackdocstheme.

Also, look at this from
openstackdocstheme/theme/openstackdocs/script_footer.html (@@ -50,17
+50,3 @@ in my patch):

gcse.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') +

Well, if I'm using file:// to browse some HTML docs, then it's going to
fetch www.google.com/cse/cse.js over a non SSL connection. That's a
security issue.

I believe there is the same issue with google analytics.

> 2. Random CDN: maxcdn, which was provided to us by the Foundation's web
> designer who gave us the design. We need CDN for performance reasons.
> What CDN meets your requirements?

Users browsing the local hard drive documentation don't want to access
an external resource, even on a CDN. It would even be slower.

The idea to speed-up browsing on the openstack.org is a very good one,
and I salute the effort to use such a CDN. But let's not forget that the
generated docs also end up in the distribution FOO-doc packages.

> 3. Non-minified JS, being worked on two bugs now. [1] [2]
> 
> Does that list capture your "ugly" claim in a measureable manner?
> 
> [1]  https://bugs.launchpad.net/openstack-manuals/+bug/1501641 
> [2]  https://bugs.launchpad.net/openstack-manuals/+bug/1502806
> 
> Not only this, but generated docs could potentially do call some of
> these objects without using HTTPS (which is the case when browsing a
> local *-doc package generated sphinx document using file://).
> 
> Could you list the calls in a bug please? That will help with triaging.

Well, last time I opened such a bug, it was closed and tagged "wontfix",
and my patch was voted out. On patch [1], it was marked as low priority
as well. I've seen no activity on #1502806 for a month and a half too.

If I open such bugs again, will there be actions on them?

> At the present moment, I would recommend projects to *not* use the
> openstackdocstheme at all until all of this is fixed.
> 
> 
> I'd like to understand your concerns further and specifically before
> taking this type of action.
> 
> I'm also thinking: am I the only one in this community that cares about
> browsing privacy?
> 
> Of course not, and with this line of reasoning and lack of clarity and
> specificity you are not representing actual privacy concerns but trying
> to manipulate emotions.

See above: I'm doing this after my bug + patch were closed, so I had no
choice but to open this kind of thread on the dev list. On the list, it
seems taken more seriously. I'm ok to take actions myself, and propose
patches, only if I have the insurance it wont just be denied.

So, even after your reply, I keep saying the same thing: until these
issues are fixed, I am giving the advice to *not* use
openstackdocstheme, because there's security concerns.

Also, please don't accuse me of trying to "manipulate emotions" after
filing explicit bugs about it: the issues are real, and I have been
explicit and specific, opening bugs in launchpad for the use of Google
Analytics.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] [client][all][neutron] client option removal policy

[Akihiro Motoki]

Thanks for the replies.
I totally agree that we should deprecate it.
We forgot to mark --request-format as deprecated.
The way we should go is to deprecate --request-format.

Akihiro

2015-12-07 21:24 GMT+09:00 Neil Jerram :
> On 07/12/15 12:01, Akihiro Motoki wrote:
>> Hi,
>>
>> neutronclient is now dropping XML support and as a result
>> "--request-format" option is no longer needed as JSON is the only format now.
>>
>> What is the recommended way for options no longer needed?
>> Does bumping major version of CLI allow us to drop an option without
>> deprecation?
>>
>> - Deprecate such option.
>>   The option still exists with only one available choiceuntil the
>> option is deleted.
>>
>> - Drop it without deprecation.
>>   This breaks users who uses "--requiest-format json", but 'json' is the 
>> default
>>   value and most users do not specify the option.
>
> I'd say it depends on how the deprecation of '--request-format xml' was
> announced.  If it said
>
> "XML format is deprecated and will be removed in a future release.  The
> only supported format will then be JSON, and so the --request-format
> option will also be removed"
>
> then the option can clearly be removed now.
>
> How was it announced?  If I look at
> http://docs.openstack.org/cli-reference/content/neutronclient_commands.html,
> I see many occurrences of
>
> *--request-format {json,xml}*
>
> The XML or JSON request format.
>
> **
>
> without anything to say that XML is deprecated.  And I see many other
> things in the same page that _are_ marked as "DEPRECATED!"  So, if I was
> reading this documentation, I would not know that XML format is deprecated.
>
> Regards,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [ironic]"No valid host was found" when creating node in Ironic

[Dmitry Tantsur]

On 12/07/2015 10:45 AM, Zhi Chang wrote:

Hi, all
 I install devstack with Ironic in physical machine. And I want to
deploy a another physical machine which IPMI info is "username:root
password:12345 ip_address: 192.168.0.100". I use this command "ironic
node-create -c d5f2dee1-f5bc-409e-a9be-a3ae5c392cfa -d ipmi_tool -p
ipmi_username=root -p ipmi_address=192.168.0.100 -p ipmi_password=12345
-n testing" to create a node in Ironic. There is an error when I run the
command. It says "No valid host was found. Reason: No conductor service
registered which supports driver ipmi_tool. (HTTP 400)". What should I
do to resolve this problem? Or, what should I do if I want to deploy a
physical machine by using Ironic?


Hello,

Please check /etc/ironic/ironic.conf. Probably your enabled_drivers 
configuration does not contain pxe_ipmitool. Please add it there and 
restart the conductor.





Thx
Zhi Chang


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




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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:
> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
> > Dmitry Tantsur wrote:
> >>
> >> 2015-12-04 18:26 GMT+01:00 Doug Hellmann  >> >:
> >>
> 
> >>
> >>  Please don't delete anything older than Mitaka.
> >>
> >>
> >> Do you have any hints how to not confuse users in this case?
> >
> > I think what Doug means is you should not delete existing closed
> > milestones like:
> > https://launchpad.net/ironic/kilo/2015.1.0
> > or:
> > https://launchpad.net/ironic/liberty/4.2.0
> > since we use the Launchpad pages there as the list of features and bugs
> > fixed for those pre-reno releases.
> >
> > Deleting those milestones would lose useful user information for no
> > gain: you can't use them anymore (since they are closed) so they are
> > unlikely to confuse anyone ?
> >
> 
> I wonder how to avoid giving impression that development has stopped on 
> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as 
> we no longer push tarballs to launchpad.
> 

I think the fact that we'll be announcing new releases by pointing
to other URLs (the releases site, for example) will help avoid that
sort of confusion. You could also add a note to the top of the project
page on launchpad.

If, over time, we see a lot of folks actually confused about the
move we can figure out a way to migrate the old data elsewhere so
it can be deleted. But that's not going to happen this cycle, so
please leave it intact for now.

Doug

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

Re: [openstack-dev] [Neutron][DVR]

[Ryan Moats]

"Armando M."  wrote on 12/04/2015 03:43:29 PM:

> From: "Armando M." 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 12/04/2015 03:44 PM
> Subject: Re: [openstack-dev] [Neutron][DVR]
>
> > On 4 December 2015 at 05:56, Ryan Moats  wrote:
> > I pretty much agree with Oleg here - I'm not sure an additional tag
> > for defects is needed.
> > The idea of a DvrImpact in the commit message is interesting, but
> > I'm not entirely convinced - if we
> > do it for one sub-project, do we need to do it for all sub-projects
> > and then what does that turn into?
> What does this mean? No other project should care about this. DVR is
> a core feature.

I'm trying to understand if (at its logical conclusion) we end up with
commit tags for all features (i.e. RbacImpact, BareMetalImpact, DbImpact,
etc.) and what that would do to the commit message...

Ryan Moats (regXboi)
__
OpenStack Development Mailing 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][nova] Orchiestrated upgrades in kolla

[Kirill Proskurin]

Jay's approach is really neat and that how it done in big productions,
sadly there is a problem with implementation of it in Kolla. I'd consider
to dig into it, maybe there is nice way to do so. If not, original approach
is ok too.

On Mon, Dec 7, 2015 at 10:06 AM, Steven Dake (stdake) 
wrote:

>
>
> On 12/6/15, 9:47 PM, "Jay Pipes"  wrote:
>
> >On 12/07/2015 04:28 AM, Michał Jastrzębski wrote:
> >> On 6 December 2015 at 09:33, Jay Pipes  wrote:
> >>>
> >>> On 12/04/2015 11:50 PM, Michał Jastrzębski wrote:
> 
>  Hey guys,
> 
>  Orchiestrated upgrades is one of our highest priorities for M in
>  kolla, so following up after discussion on summit I'd like to
>  suggest an approach:
> 
>  Instead of creating playbook called "upgrade my openstack" we
>  will create "upgrade my nova" instead and approach to each
>  service case by case (since all of our running services are in
>  dockers, this is possible). We will also make use of image tags
>  as version carriers, so ansible will deploy new container only if
>  version tag differs from what we ask it to deploy. This will help
>  with idempotency of upgrade process.
> 
>  So let's start with nova. Upgrade-my-nova playbook will do
>  something like this:
> 
>  0. We create snapshot of our mariadb-data container. This will
>  affect every service, but it's always good to have backup and
>  rollback of db will be manual action
> 
>  1. Nova bootstrap will be called and it will perform
>  db-migration. Since current approach to nova code is add-only we
>  shouldn't need to stop services and old services should keep
>  working on newer database. Also for minor version upgrades there
>  will be no action here unless there is migration. 2. We upgrade
>  all conductor at the same time. This should take mere seconds
>  since we'll have prebuilt containers 3. We will upgrade rest of
>  controller services with using "series: 1" in ansible to ensure
>  rolling upgrades. 4. We will upgrade all of nova-compute services
>  on it's own pace.
> 
>  This workflow should be pretty robust (I think it is) and it
>  should also provide idempotency.
> >>>
> >>>
> >>> From Nova's perspective, most of the above looks OK to me, however,
> >>> I am in more in favor of an upgrade strategy that builds a "new"
> >>> set of conductor or controller service containers all at once and
> >>> then flips the VIP or managed IP from the current controller pod
> >>> containers to the newly-updated controller pod containers.
> >>
> >> Well, we can't really do that because that would affect all other
> >> services on controller host, and we want to minimize impact on rest
> >> of cluster during upgrade. Containers gives us option to upgrade
> >> "just nova", or even "just nova conductors" without affecting
> >> anything else. On the bright side, redeploying pre-built container is
> >> a matter of seconds (or even less). Whole process from turning off
> >> last conductor to spawn first new conductor should take less than
> >> 10s, and that's only downtime we should get there.
> >
> >Sorry, I guess I wasn't clear. I was not proposing to put all controller
> >services in a single container. I was proposing simply to build the
> >various container sets (nova-conductor, nova-api, etc) with the updated
> >code for that service and then "flip the target IP or port" for that
> >particular service from the existing container set's VIP to the
> >new/updated container set's VIP.
> >
> >In Kubernetes-speak, you would create a new Pod with containers having
> >the updated Nova conductor code, and would set the new Pod's selector to
> >something different than the existing Pod's selector -- using the Git
> >SHA1 hash for the selector would be perfect... You would then update the
> >Service object's selector to target the new Pod instead of the old one.
> >
> >Or, alternately, you could use Kubernetes' support for rolling updates
> >[1] of a service using a ReplicationController that essentially does the
> >Pod and Service orchestration for you.
> >
> >Hope that is a little more clear what I was referring to...
> >
> >Best,
> >-jay
>
> Jay,
>
> Forgive me if this is a little incoherent - I have a root canal scheduled
> for tomorrow with the fun-filled day that comes  comes with :(
>
> We don't use docker-proxy in kolla.  Instead we use net=host mode.  I
> think what you propose would require an extra global VIP for upgrades (or
> using docker-proxy, which we don't want to do). I am not really hot on
> this approach for that reason.
>
> Regards
> -stee
>
> >
> >[1]
> >
> https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/repli
> >cation-controller.md#rolling-updates
> >
> >>> This seems to me to be the most efficient (in terms of minimal
> >>> overall downtime) and most robust (because a "rollback" is simply
> >>> flipping the VIP back to the original controller

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Dmitry Tantsur]

On 12/07/2015 02:42 PM, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:

On 12/07/2015 10:48 AM, Thierry Carrez wrote:

Dmitry Tantsur wrote:


2015-12-04 18:26 GMT+01:00 Doug Hellmann mailto:d...@doughellmann.com>>:





  Please don't delete anything older than Mitaka.


Do you have any hints how to not confuse users in this case?


I think what Doug means is you should not delete existing closed
milestones like:
https://launchpad.net/ironic/kilo/2015.1.0
or:
https://launchpad.net/ironic/liberty/4.2.0
since we use the Launchpad pages there as the list of features and bugs
fixed for those pre-reno releases.

Deleting those milestones would lose useful user information for no
gain: you can't use them anymore (since they are closed) so they are
unlikely to confuse anyone ?



I wonder how to avoid giving impression that development has stopped on
4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as
we no longer push tarballs to launchpad.



I think the fact that we'll be announcing new releases by pointing
to other URLs (the releases site, for example) will help avoid that
sort of confusion. You could also add a note to the top of the project
page on launchpad.


+1



If, over time, we see a lot of folks actually confused about the
move we can figure out a way to migrate the old data elsewhere so
it can be deleted. But that's not going to happen this cycle, so
please leave it intact for now.


Understood, thanks for explanation. So I withdraw suggestion #2.



Doug

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




__
OpenStack Development Mailing 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][docs][api] Propose Virtual Nova API Doc Sprint on Dec 8 and 9

[Anita Kuno]

On 12/04/2015 09:48 AM, Alex Xu wrote:
> Just reminder the event which close the time, the virtual doc sprint is
> right next week. Welcome to join us!

Please include the details of your virtual sprint on the virtual sprints
wikipage: https://wiki.openstack.org/wiki/VirtualSprints

Thank you,
Anita.

> 
> 2015-11-11 20:51 GMT+08:00 Alex Xu :
> 
>> Hi,
>>
>> At nova api subteam weekly meeting, we decided hold 2 days virtual doc
>> sprint to help the Nova API document. The initial proposed date is Dec 8
>> and 9(Let me know if the date is conflict with other thing). The sprint is
>> running on local time for folks. Peoples can work on the patch and also can
>> help on the review.
>>
>> Appreciate and welcome people join this sprint to help on API doc.
>>
>> Please sign up for this sprint first if you are interesting at the top of
>> etherpad https://etherpad.openstack.org/p/nova-v2.1-api-doc . The tasks
>> of sprint are also in the etherpad, already have some contributors work on
>> those doc tasks now, so free to join us now or join the sprint.
>>
>> Thanks
>> Alex
>>
> 
> 
> 
> __
> OpenStack Development Mailing 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] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Morgan Fainberg]

On Mon, Dec 7, 2015 at 7:54 AM, Thomas Goirand  wrote:

> On 12/04/2015 03:23 PM, Anne Gentle wrote:
> >
> >
> > On Fri, Dec 4, 2015 at 8:09 AM, Thomas Goirand  > > wrote:
> >
> > Hi,
> >
> > I've investigated a bit the openstackdocstheme, and tried to remove
> some
> > of the (numerous) javascript with external references. And it's
> *very*
> > ugly: it's full of google stuff, random CDN and so on.
> >
> >
> > I absolutely want to address these concerns.
>
> Hi,
>
> Thanks for replying.
>
> Let me start by this. In Debian, I'm adding this patch:
>
>
> http://anonscm.debian.org/cgit/openstack/python-openstackdocstheme.git/tree/debian/patches/patch-out-external-references.patch
>
> Now, let me explain why.
>
> > Let's start with making sure I understand the concerns so we can start
> > tracking the work requirements with bugs.
> >
> > 1. Google stuff, considered non-free. Can you list specifics? Fonts and
> > analytics js for starters, let me know if there are others?
>
> It's not only about non-freeness, it's also about the fact that I don't
> want Google to know when I'm browsing my local hard drive HTML, which it
> would when browsing any OpenStack docs generated by OpenStack packages
> in Debian, without the Debian patch to openstackdocstheme.
>
> Also, look at this from
> openstackdocstheme/theme/openstackdocs/script_footer.html (@@ -50,17
> +50,3 @@ in my patch):
>
> gcse.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') +
>
> Well, if I'm using file:// to browse some HTML docs, then it's going to
> fetch www.google.com/cse/cse.js over a non SSL connection. That's a
> security issue.
>
> I believe there is the same issue with google analytics.
>
> > 2. Random CDN: maxcdn, which was provided to us by the Foundation's web
> > designer who gave us the design. We need CDN for performance reasons.
> > What CDN meets your requirements?
>
> Users browsing the local hard drive documentation don't want to access
> an external resource, even on a CDN. It would even be slower.
>
> The idea to speed-up browsing on the openstack.org is a very good one,
> and I salute the effort to use such a CDN. But let's not forget that the
> generated docs also end up in the distribution FOO-doc packages.
>
>
I think that this falls into the category that we need a way to add in the
CDN information for the related resources when generating the docs. The
publish job that pushes this data up to the actual websites can handle the
toggling this change. This should totally be both reasonable and accepted
(will require an infra change as well long term). I agree that the use of
the CDN for local docs is not the right choice. Clearly this is a
bug/enhancement that should be made.


> > 3. Non-minified JS, being worked on two bugs now. [1] [2]
> >
> > Does that list capture your "ugly" claim in a measureable manner?
> >
> > [1]  https://bugs.launchpad.net/openstack-manuals/+bug/1501641
> > [2]  https://bugs.launchpad.net/openstack-manuals/+bug/1502806
> >
> > Not only this, but generated docs could potentially do call some of
> > these objects without using HTTPS (which is the case when browsing a
> > local *-doc package generated sphinx document using file://).
> >
> > Could you list the calls in a bug please? That will help with triaging.
>
> Well, last time I opened such a bug, it was closed and tagged "wontfix",
> and my patch was voted out. On patch [1], it was marked as low priority
> as well. I've seen no activity on #1502806 for a month and a half too.


> If I open such bugs again, will there be actions on them?
>
> > At the present moment, I would recommend projects to *not* use the
> > openstackdocstheme at all until all of this is fixed.
> >
> >
> > I'd like to understand your concerns further and specifically before
> > taking this type of action.
> >
> > I'm also thinking: am I the only one in this community that cares
> about
> > browsing privacy?
> >
> > Of course not, and with this line of reasoning and lack of clarity and
> > specificity you are not representing actual privacy concerns but trying
> > to manipulate emotions.
>
> See above: I'm doing this after my bug + patch were closed, so I had no
> choice but to open this kind of thread on the dev list. On the list, it
> seems taken more seriously. I'm ok to take actions myself, and propose
> patches, only if I have the insurance it wont just be denied.
>
>
There is never insurance that the patches wont be denied, but I think
you've made some reasonable arguments as to why these should be
updated/changed. I think that the non-free aspect is a bit more serious (in
my world view) than the privacy aspect for google knowing I'm looking at
docs on my local hard disk. I do also get that we all have different
priorities and they are not guaranteed to be in-sync.


> So, even after your reply, I keep saying the same thing: until these
> issues are fixed, I am giving the advice to *not* use

[openstack-dev] [Fuel] [QA] [Tests] MOS integration tests in SWARM test suite

[Timur Nurlygayanov]

Hi Fuel team,

we have a lot of automated integration tests for OpenStack verification and
we want to add execution of these tests to Fuel SWARM test suite (to run
these tests on daily basis and on per commit basis).

We used our own bash scripts to deploy OpenStack environments with Fuel
before, but now we have no resources to maintain these scripts. Fuel QA and
MOS QA teams invest a lot of efforts to improve existing QA framework with
BVT/SWARM tests. This is why we want to add our integration automated tests
to SWARM test suite, where we already have good framework to manage fuel
environments.

We started to move our integration tests to SWARM test suite:
1. Sahara integration tests with deployment of all available Sahara cluster
/ plugins types:
https://review.openstack.org/#/c/248602/ (merged)
2. Murano integration tests with deployment of all available Murano
applications:
https://review.openstack.org/#/c/249850/(on review)

We are going to add execution of full Tempest tests suite [1] and execution
of all CLI-based functional tests [2] from upstream projects.
These tests will be executed on separate hardware server, where we will
have enough resources (for example, integration Murano and Sahara tests
require 32 Gb of RAM on compute nodes minimum). We already provided this
server to fuel CI team.

We want to merge these tests before MOS 8.0 to do all acceptance testing
with automated tests (and without manual testing).

In parallel, we are working on new approach of integration of third-party
functional / integration tests with SWARM test suite. It is under the
discussion now and it will be not available in the nearest future.

Please, let me know if you have objections or questions.

[1] https://bugs.launchpad.net/fuel/+bug/1523515
[2] https://bugs.launchpad.net/fuel/+bug/1523436

-- 

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Rico Lin for heat-core

[Zane Bitter]

On 07/12/15 07:39, Sergey Kraynev wrote:

Hi all.

I'd like to nominate Rico Lin for heat-core. He did awesome job with
providing useful and valuable reviews. Also his contribution is really
high [1] .

[1] http://stackalytics.com/report/contribution/heat-group/60

Heat core-team, please vote with:
  +1 - if you agree
   -1 - if you disagree


I think anyone who can do things like reworking exceptions without 
breaking obscure stuff like the cfn API is probably developing a deep 
understanding of the code base :) Combined with the review stats, that 
gets my +1.


cheers,
Zane.

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

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

[Coffman, Joel M.]

On 12/2/15, 4:01 PM, "Ben Swartzlander"  wrote:

>On 11/30/2015 09:04 AM, Coffman, Joel M. wrote:
>>
>>
>> On 11/25/15, 11:33 AM, "Ben Swartzlander" > > wrote:
>>
>> On 11/24/2015 03:27 PM, Nathan Reller wrote:
>>
>> the cinder admin and the nova admin are ALWAYS the same
>>people
>>
>>
>> There is interest in hybrid clouds where the Nova and Cinder
>> services
>> are managed by different providers. The customer would place
>>higher
>> trust in Nova because you must trust the compute service, and
>>the
>> customer would place less trust in Cinder. One way to achieve
>>this
>> would be to have all encryption done by Nova. Cinder would
>> simply see
>> encrypted data and provide a good cheap storage solution for
>>data.
>>
>> Consider a company with sensitive data. They can run the compute
>> nodes
>> themselves and offload Cinder service to some third-party
>>service.
>> This way they are the only ones who can manage the machines
>>that see
>> the plaintext.
>>
>>
>> If you have that level of paranoia, I suggest running LUKS inside
>>the
>> guest VM and not relying on OpenStack to handle your encryption.
>>Then
>> you don't have to worry about whether nova is sharing your keys with
>> cinder because even nova won't have them.
>>
>> That approach isn't actually more secure — anyone with root access to
>> the compute host can dump the VM's memory to extract the encryption
>>keys.
>
>I agree, however in the above case there was implied trust in the
>compute infrastructure -- at least more so than in the storage
>infrastructure. If you don't trust your hypervisor admin to not read
>your VM memory and steal encryption keys, then relying on your
>hypervisor admin (or nova) to perform the encryption is kind of silly.
>In every case, the hypervisor admin can see the plaintext and the keys.
>
>The suggestion was a way to achieve the goal of doing encryption WITHOUT
>trusting the storage admin and WITHOUT CHANGING ANY CODE. I assert that
>any attempt to implement encryption at the nova level and not sharing
>keys with cinder will break the existing model. There are 2 solutions I
>can see:
>1) don't break it (see above)
>2) you break it, you fix it (nova takes over responsibility for all the
>operations cinder currently performs that involve plaintext).
So perhaps it would be fair to describe the existing encryption support as
comparable to the proposal to use LUKS inside the guest VM?

>> Trying to design a system where we expect nova to do data
>>encryption but
>> not cinder will not work in the long run. The eventual result will
>>be
>> that nova will have to take on most of the functionality of cinder
>>and
>> we'll be back to the nova-volume days.
>>
>> Could you explain further what you mean by "nova will have to take on
>> most of the functionality of cinder"? In the current design, Nova is
>> still passing data blocks to Cinder for storage – they're just encrypted
>> instead of plaintext. That doesn't seem to subvert the functionality of
>> Cinder or reimplement it.
>
>I think Duncan covered it, but the data operations cinder currently
>performs, which require Cinder to touch plaintext data are:
>1) Create volume from glance image
>2) Create glance image from volume
>3) Backup volume
>4) Restore volume
>
>I'm not claiming that we can't redefine or alter the above operations to
>deal with encryption, but someone needs to propose how they should work
>differently or work at all when the volume isn't storing plaintext data.
The operations listed seem to have the same issues with encryption inside
a VM and the existing implementation.
1) Create volume from Glance image: Since Glance doesn't support
encryption (yet), this volume would be unencrypted and any discussion
about encryption is a moot point.
2) Create Glance image from volume: If the volume is encrypted (using
encryption inside the VM or the current implementation), then eventually
trying to use this image to boot a VM will fail *unless* there is a way to
provide the key when the image is spawned. If Glance eventually supports
the same encryption metadata as Cinder, then the current implementation
should "just work."
3) Backup / restore volume: Encryption inside the VM has the same issues
as the current implementation.

Of course, both techniques (encryption inside a VM and the current
implementation) have significant implications regarding compression,
de-duplication, etc. That was the original rationale for including the
'control-location' parameter: it explicitly admits multiple ways of
handling the encryption and would allow users to determine if the
additional storage cost is worth it.


>> Also in case it's not obvious, if you use different providers for
>> compute and storage, your performance is going to be absolutely
>> terrible.
>>
>> The general idea is 

Re: [openstack-dev] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Jeremy Stanley]

On 2015-12-07 09:04:20 -0500 (-0500), Morgan Fainberg wrote:
[...]
> * We should not (regardless of free/non-free/etc) make sure that the docs
> are fully self-contained when built locally. This would address the privacy
> and security issues for the local docs. (Again Analytics can be enabled as
> a build-time job).

Assuming s/not// (looks like a typo?) I'm in complete agreement.

> * We should ensure we are only loading any external sources via HTTPS
> rather than HTTP.

Or better yet, not loading any external sources at all (though
figuring out how to find and link to locally installed distro
packages of fonts and similar resources might get complicated, and
so may still be easier left as distro-specific patches in their
respective packaging).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [heat] Rico Lin for heat-core

[Randall Burt]

+1

 Original message 
From: Sergey Kraynev
Date:12/07/2015 6:41 AM (GMT-06:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [heat] Rico Lin for heat-core

Hi all.

I'd like to nominate Rico Lin for heat-core. He did awesome job with providing 
useful and valuable reviews. Also his contribution is really high [1] .

[1] http://stackalytics.com/report/contribution/heat-group/60

Heat core-team, please vote with:
 +1 - if you agree
  -1 - if you disagree

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

Re: [openstack-dev] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Anne Gentle]

On Mon, Dec 7, 2015 at 8:04 AM, Morgan Fainberg 
wrote:

>
>
> On Mon, Dec 7, 2015 at 7:54 AM, Thomas Goirand  wrote:
>
>> On 12/04/2015 03:23 PM, Anne Gentle wrote:
>> >
>> >
>> > On Fri, Dec 4, 2015 at 8:09 AM, Thomas Goirand > > > wrote:
>> >
>> > Hi,
>> >
>> > I've investigated a bit the openstackdocstheme, and tried to remove
>> some
>> > of the (numerous) javascript with external references. And it's
>> *very*
>> > ugly: it's full of google stuff, random CDN and so on.
>> >
>> >
>> > I absolutely want to address these concerns.
>>
>> Hi,
>>
>> Thanks for replying.
>>
>> Let me start by this. In Debian, I'm adding this patch:
>>
>>
>> http://anonscm.debian.org/cgit/openstack/python-openstackdocstheme.git/tree/debian/patches/patch-out-external-references.patch
>>
>> Now, let me explain why.
>>
>> > Let's start with making sure I understand the concerns so we can start
>> > tracking the work requirements with bugs.
>> >
>> > 1. Google stuff, considered non-free. Can you list specifics? Fonts and
>> > analytics js for starters, let me know if there are others?
>>
>> It's not only about non-freeness, it's also about the fact that I don't
>> want Google to know when I'm browsing my local hard drive HTML, which it
>> would when browsing any OpenStack docs generated by OpenStack packages
>> in Debian, without the Debian patch to openstackdocstheme.
>>
>> Also, look at this from
>> openstackdocstheme/theme/openstackdocs/script_footer.html (@@ -50,17
>> +50,3 @@ in my patch):
>>
>> gcse.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') +
>>
>> Well, if I'm using file:// to browse some HTML docs, then it's going to
>> fetch www.google.com/cse/cse.js over a non SSL connection. That's a
>> security issue.
>>
>> I believe there is the same issue with google analytics.
>>
>> > 2. Random CDN: maxcdn, which was provided to us by the Foundation's web
>> > designer who gave us the design. We need CDN for performance reasons.
>> > What CDN meets your requirements?
>>
>> Users browsing the local hard drive documentation don't want to access
>> an external resource, even on a CDN. It would even be slower.
>>
>> The idea to speed-up browsing on the openstack.org is a very good one,
>> and I salute the effort to use such a CDN. But let's not forget that the
>> generated docs also end up in the distribution FOO-doc packages.
>>
>>
> I think that this falls into the category that we need a way to add in the
> CDN information for the related resources when generating the docs. The
> publish job that pushes this data up to the actual websites can handle the
> toggling this change. This should totally be both reasonable and accepted
> (will require an infra change as well long term). I agree that the use of
> the CDN for local docs is not the right choice. Clearly this is a
> bug/enhancement that should be made.
>
>
>> > 3. Non-minified JS, being worked on two bugs now. [1] [2]
>> >
>> > Does that list capture your "ugly" claim in a measureable manner?
>> >
>> > [1]  https://bugs.launchpad.net/openstack-manuals/+bug/1501641
>> > [2]  https://bugs.launchpad.net/openstack-manuals/+bug/1502806
>> >
>> > Not only this, but generated docs could potentially do call some of
>> > these objects without using HTTPS (which is the case when browsing a
>> > local *-doc package generated sphinx document using file://).
>> >
>> > Could you list the calls in a bug please? That will help with triaging.
>>
>> Well, last time I opened such a bug, it was closed and tagged "wontfix",
>> and my patch was voted out. On patch [1], it was marked as low priority
>> as well. I've seen no activity on #1502806 for a month and a half too.
>
>
>> If I open such bugs again, will there be actions on them?
>>
>> > At the present moment, I would recommend projects to *not* use the
>> > openstackdocstheme at all until all of this is fixed.
>> >
>> >
>> > I'd like to understand your concerns further and specifically before
>> > taking this type of action.
>> >
>> > I'm also thinking: am I the only one in this community that cares
>> about
>> > browsing privacy?
>> >
>> > Of course not, and with this line of reasoning and lack of clarity and
>> > specificity you are not representing actual privacy concerns but trying
>> > to manipulate emotions.
>>
>> See above: I'm doing this after my bug + patch were closed, so I had no
>> choice but to open this kind of thread on the dev list. On the list, it
>> seems taken more seriously. I'm ok to take actions myself, and propose
>> patches, only if I have the insurance it wont just be denied.
>>
>>
> There is never insurance that the patches wont be denied, but I think
> you've made some reasonable arguments as to why these should be
> updated/changed. I think that the non-free aspect is a bit more serious (in
> my world view) than the privacy aspect for google knowing I'm looking at
> docs on my local hard disk. I do also get that we all hav

Re: [openstack-dev] [Nova] notification subteam meeting

[Balázs Gibizer]

Hi, 

The next meeting of the nova notification subteam will happen 2015-12-08 
Tuesday 20:00 UTC [1] on #openstack-meeting-alt on freenode 

Agenda:
- Status of the outstanding specs and code reviews
- AOB

See you there.

Cheers,
Gibi

 [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151208T20 
 [2] https://wiki.openstack.org/wiki/Meetings/NovaNotification


__
OpenStack Development Mailing 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][docs][api] Propose Virtual Nova API Doc Sprint on Dec 8 and 9

[Alex Xu]

Anita, thanks for the reminder, so cool we have such wiki, just add my one.

2015-12-07 21:49 GMT+08:00 Anita Kuno :

> On 12/04/2015 09:48 AM, Alex Xu wrote:
> > Just reminder the event which close the time, the virtual doc sprint is
> > right next week. Welcome to join us!
>
> Please include the details of your virtual sprint on the virtual sprints
> wikipage: https://wiki.openstack.org/wiki/VirtualSprints
>
> Thank you,
> Anita.
>
> >
> > 2015-11-11 20:51 GMT+08:00 Alex Xu :
> >
> >> Hi,
> >>
> >> At nova api subteam weekly meeting, we decided hold 2 days virtual doc
> >> sprint to help the Nova API document. The initial proposed date is Dec 8
> >> and 9(Let me know if the date is conflict with other thing). The sprint
> is
> >> running on local time for folks. Peoples can work on the patch and also
> can
> >> help on the review.
> >>
> >> Appreciate and welcome people join this sprint to help on API doc.
> >>
> >> Please sign up for this sprint first if you are interesting at the top
> of
> >> etherpad https://etherpad.openstack.org/p/nova-v2.1-api-doc . The tasks
> >> of sprint are also in the etherpad, already have some contributors work
> on
> >> those doc tasks now, so free to join us now or join the sprint.
> >>
> >> Thanks
> >> Alex
> >>
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] [kolla][nova] Orchiestrated upgrades in kolla

[Dan Smith]

>> 1. Nova bootstrap will be called and it will perform db-migration. Since
>> current approach to nova code is add-only we shouldn't need to stop
>> services and old services should keep working on newer database. Also
>> for minor version upgrades there will be no action here unless there is
>> migration.
>> 2. We upgrade all conductor at the same time. This should take mere
>> seconds since we'll have prebuilt containers
>> 3. We will upgrade rest of controller services with using "series: 1" in
>> ansible to ensure rolling upgrades.

Technically, 2 and 3 need to go at the same time. We have some machinery
in place to help us not do online data conversions until all the control
services are upgraded, but we haven't been through one of those yet to
prove it out. Since the rest of the control services are mostly
stateless, I would recommend just squashing those two steps together for
the time being.

>> 4. We will upgrade all of nova-compute services on it's own pace.

Don't forget the final step of unpinning everyone's compute rpc version
once you're done. If you're using version=auto for compute, you will
soon be able to SIGHUP the services to get them to recalculate the
version pin without restarting.

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

--Dan

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

Re: [openstack-dev] [ironic]"No valid host was found" when creatingnode in Ironic

[Zhi Chang]

Hi, thanks for your reply. You are right, I forgot to load some drivers in 
Ironic. But there is another problem. When I run the command "ironic 
node-set-power-state xxx off", ironic conductor displays an error, says "IPMI 
Error while attempting ipmitool -I lanplus -H 10.0.8.65 -L ADMINISTRATOR -U 
root -R 12 -N 5 -f /tmp/tmpboxKdA power status". And log says "Unable to 
establish IPMI v2 / RMCP+ session unable to get chassis power status".  But 
this command runs well in shell after I input the password of IPMI. 
Could you tell me what's wrong with the Ironic? 


Thanks a lot
Zhi Chang
 
 
-- Original --
From:  "Dmitry Tantsur";
Date:  Mon, Dec 7, 2015 09:08 PM
To:  "openstack-dev"; 

Subject:  Re: [openstack-dev] [ironic]"No valid host was found" when 
creatingnode in Ironic

 
On 12/07/2015 10:45 AM, Zhi Chang wrote:
> Hi, all
>  I install devstack with Ironic in physical machine. And I want to
> deploy a another physical machine which IPMI info is "username:root
> password:12345 ip_address: 192.168.0.100". I use this command "ironic
> node-create -c d5f2dee1-f5bc-409e-a9be-a3ae5c392cfa -d ipmi_tool -p
> ipmi_username=root -p ipmi_address=192.168.0.100 -p ipmi_password=12345
> -n testing" to create a node in Ironic. There is an error when I run the
> command. It says "No valid host was found. Reason: No conductor service
> registered which supports driver ipmi_tool. (HTTP 400)". What should I
> do to resolve this problem? Or, what should I do if I want to deploy a
> physical machine by using Ironic?

Hello,

Please check /etc/ironic/ironic.conf. Probably your enabled_drivers 
configuration does not contain pxe_ipmitool. Please add it there and 
restart the conductor.

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


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

Re: [openstack-dev] [nova][docs][api] Propose Virtual Nova API Doc Sprint on Dec 8 and 9

[Anita Kuno]

On 12/07/2015 09:45 AM, Alex Xu wrote:
> Anita, thanks for the reminder, so cool we have such wiki, just add my one.

Thank you Alex, I hope you have a good sprint.

Anita.

> 
> 2015-12-07 21:49 GMT+08:00 Anita Kuno :
> 
>> On 12/04/2015 09:48 AM, Alex Xu wrote:
>>> Just reminder the event which close the time, the virtual doc sprint is
>>> right next week. Welcome to join us!
>>
>> Please include the details of your virtual sprint on the virtual sprints
>> wikipage: https://wiki.openstack.org/wiki/VirtualSprints
>>
>> Thank you,
>> Anita.
>>
>>>
>>> 2015-11-11 20:51 GMT+08:00 Alex Xu :
>>>
 Hi,

 At nova api subteam weekly meeting, we decided hold 2 days virtual doc
 sprint to help the Nova API document. The initial proposed date is Dec 8
 and 9(Let me know if the date is conflict with other thing). The sprint
>> is
 running on local time for folks. Peoples can work on the patch and also
>> can
 help on the review.

 Appreciate and welcome people join this sprint to help on API doc.

 Please sign up for this sprint first if you are interesting at the top
>> of
 etherpad https://etherpad.openstack.org/p/nova-v2.1-api-doc . The tasks
 of sprint are also in the etherpad, already have some contributors work
>> on
 those doc tasks now, so free to join us now or join the sprint.

 Thanks
 Alex

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


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

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Stanislaw,

the reason why I'm considering splitting the blueprint is that along with
implementing the feature, CI jobs and OSTF must be fixed as well.

On Mon, Dec 7, 2015 at 4:03 AM, Stanislaw Bogatkin 
wrote:

> Hi Dmitry,
>
> thank you for an update.
> I personally think that 2 and 3 must be done in one blueprint as it
> related to master node only and 2 shouldn't be a rocket science. What you
> mean by "Non-root accounts on slave nodes"? If we speak about disabling
> root for ssh, creating new user and adding needed commands for him in
> sudoers - I believe that it can be done in that blueprint too. If it is
> something much bigger - it worth to be in separate blueprint.
>
> On Fri, Dec 4, 2015 at 8:24 PM, Dmitry Nikishov 
> wrote:
>
>> Folks, there is another spec update, please take a look:
>> https://review.openstack.org/#/c/243340
>>
>> I'm also considering splitting the blueprint/spec into smaller pieces:
>>
>> 1. Non-root accounts on slave nodes.
>> 2. Non-root user account (fueladmin) on master node.
>> 3. Running fuel services as non-superuser.
>> 4. Running mcollective as non-root (tentative, still need a POC).
>>
>> Let me know what you think.
>>
>> On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov > > wrote:
>>
>>> Folks, I have updated a spec, please review:
>>> https://review.openstack.org/#/c/243340
>>>
>>> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov >> > wrote:
>>>
 Stanislaw,

 proposing patches could be a viable option long-term, however, by the
 time these patches will make it upstream, Fuel will use CentOS 7 w/ 
 systemd.

 On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Dmitry, as we work on opensource - it would be really nice to propose
> patches to upstream for non-Fuel services. But if it is not an option -
> using puppet make sense to me.
>
> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
> dnikis...@mirantis.com> wrote:
>
>> Stanislaw,
>>
>> I want to clarify: there are 2 types of services, run on the Fuel
>> node:
>> - Those, which are a part of Fuel (astute, nailgun etc)
>> - Those, which are not (e.g. atop)
>>
>> Capabilities for the former can easily be managed via post-install
>> scripts, embedded in respective package spec file (since specs are a part
>> of fuel-* repo). This is a very good idea.
>> Capabilities for the latter will have to be taken care of via either
>> a. some external utility (puppet)
>> b. rebuilding respective package with updated spec
>>
>> I'd say that (a) is still more convinient.
>>
>> Another option would be to have a fine-grained control only on Fuel
>> services and leave all the other at their defaults.
>>
>> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Dmitry, I just propose the way I think is right, because it's
>>> strange enough - install package from *.deb file and then set any
>>> privileges to it by third-party utility. Set permissions for app now 
>>> mostly
>>> managed by post-install scripts. Moreover - if it isn't - it should, 
>>> cause
>>> if you set capabilities by puppet there always will be a gap between
>>> installation and setting permissions, so you will must bound package
>>> installation process with setting permissions by puppet - other way you
>>> will have no way to use your app.
>>>
>>> Setting setuid bits on apps is not a good idea - it is why linux
>>> capabilities were introduced.
>>>
>>> On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 Stanislaw,

 In my opinion the whole feature shouldn't be in the separate
 package simply because it will actually affect the code of many, if not
 all, components of Fuel.

 The only services whose capabilities will have to be managed by
 puppet are those, which are installed from upstream packages (e.g. 
 atop) --
 not built from fuel-* repos.

 Supervisord doesn't seem to use Linux capabilities, id does setuid
 instead:
 https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326

 On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Dmitry, I mean whole feature.
> Btw, why do you want to grant capabilities via puppet? It should
> be done by post-install package section, I believe.
>
> Also I doesn't know if supervisord can bound process capabilities
> like systemd can - we could use this opportunity too.
>
> On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <
> dnikis...@mirantis.com> wrote:
>
>> My main concern with using linux capabilitie

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

[AFEK, Ifat (Ifat)]

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Monday, December 07, 2015 12:00 PM
>
> I find it odd to have UI use cases first, as their terribly large for a
> MVP. Unless Vitrage already exists and you have all the code figured
> out. :)

We have most of it figured out.
We have an RCA engine written in java as a proprietary CloudBand code, 
with UI for showing the topology and RCA, and it is already working 
in production environments. 
We have decided to write a similar project in python as part of 
OpenStack project. Obviously, writing in OpenStack brings up new 
challenges which we are now trying to solve.

> > In case you haven't seen in yet, our high level architecture is on
> > Vitrage main page[2], and in the coming days we plan to document also
> > the lower level design.
> 
> I just looked at it, at it's very interesting. All the high level
> functionalities make sense and provide values. But if you try to solve
> them all 5 at once, I'm afraid you're going to either build a monster
> (with a lot of overlap with other projects, hard to maintain, etc) or
> just crash because you'll be blocked by all other OpenStack projects.
> That's the big issue when starting to build a project on top of others
> OpenStack bricks.
> 
> Overall I'm just saying that because it's still not clear to me which
> part you're trying to solve in this thread and how we can help you.
> What can we provide in our projects, that you miss, that could help
> you, concretely? What feature we need to work on next?
> 
> It would be awesome to have _one_ use-case described end-to-end that
> you would like to solve with Vitrage, leveraging various OpenStack
> projects, that you cannot solve right now because of missing pieces.
> Then we could start identifying these missing pieces and implement/fix
> them. :-)

We are not going to implement 5 use cases at once :-)
We will start with the physical-to-virtual mapping + a UI for visualizing 
this topology. This is the basic functionality for our next use cases.
Next, we will move to the RCA and the deduced alarms use cases. Alarm 
aggregation probably won't be implemented for mitaka.


Let me describe in details the deduced alarms use case.

1. Vitrage gets an alarm from Nagios about a public switch failure

2. Vitrage evaluator decides (based on its templates) that an "Instance is 
at risk due to public switch problem" alarm should be triggered for every 
instance on every host attached to this public switch

3. Vitrage notifier creates corresponding alarm definitions in Aodh 

4. Aodh stores these alarms in its database 

5. Vitrage triggers the alarms (sets their states)

6. Aodh updates the alarms states and notifies about it 

7. Horizon user queries Aodh for a list of all alarms. Aodh returns a list 
that includes the alarms that were triggered by Vitrage.

The added value of this use case, is that the Cloud Admin can see that
some instances are at risk, even thought their Nova statuses are ok.

For the integration with Aodh, we need the ability to create alarm
definitions that are not based on metrics, and to trigger them ourselves.

What do you think?


Thanks for your feedback, it is very helpful! 

Ifat and Alexey.



















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

Re: [openstack-dev] [TripleO] workflow

[Dan Prince]

On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:
> On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
> > On 23 November 2015 at 14:37, Dan Prince 
> > wrote:
> > > There are lots of references to "workflow" within TripleO
> > > conversations
> > > these days. We are at (or near) the limit of what we can do
> > > within
> > > Heat
> > > with regards to upgrades. We've got a new TripleO API in the
> > > works
> > > (a
> > > new version of Tuskar basically) that is specifically meant to
> > > encapsulates business logic workflow around deployment. And, Lots
> > > of
> > > interest in using Ansible for this and that.
> > > 
> > > So... Last week I spent a bit of time tinkering with the Mistral
> > > workflow service that already exists in OpenStack and after a few
> > > patches got it integrated into my undercloud:
> > > 
> > > https://etherpad.openstack.org/p/tripleo-undercloud-workflow
> > > 
> > > One could imagine us coming up with a set of useful TripleO
> > > workflows
> > > (something like this):
> > > 
> > >  tripleo.deploy 
> > >  tripleo.update 
> > >  tripleo.run_ad_hoc_whatever_on_specific_roles <>
> > > 
> > > Since Mistral (the OpenStack workflow service) can already
> > > interact
> > > w/
> > > keystone and has a good many hooks to interact with core
> > > OpenStack
> > > services like Swift, Heat, and Nova we might get some traction
> > > very
> > > quickly here. Perhaps we add some new Mistral Ironic actions? Or
> > > imagine smaller more focused Heat configuration stacks that we
> > > drive
> > > via Mistral? Or perhaps we tie in Zaqar (which already has some
> > > integration into os-collect-config) to run ad-hoc deployment
> > > snippets
> > > on specific roles in an organized fashion?  Or wrapping mistral
> > > w/
> > > tripleoclient to allow users to more easily call TripleO specific
> > > workflows (enhancing the user feedback like we do with our
> > > heatclient
> > > wrapping already)?
> > > 
> > > Where all this might lead... I'm not sure. But I feel like we
> > > might
> > > benefit by adding a few extra options to our OpenStack deployment
> > > tool
> > > chain.
> > I think this sounds promising. Lots of the code in the CLI is about
> > managing workflows. For example when doing introspection we change
> > the node state, poll for the result, start introspection, poll for
> > the result, change the node state back and poll for the result. If
> > mistral can help here I expect it could give us a much more robust
> > solution.
> 
> Hows this look:
> 
> https://github.com/dprince/tripleo-mistral-
> workflows/blob/master/tripleo/baremetal.yaml

I made a short (13 minute) video demonstration that outlines what using
Mistral might look like in TripleO. The demo uses the above workflow as
an example.

https://youtu.be/bnAT37O-sdw


Dan

> 
> > 
> > >  Dan
> > > 
> > > _
> > > __
> > > ___
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > su
> > > bscribe
> > > 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:unsu
> > bs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

[Michał Jastrzębski]

So Dan, correct me if I'm wrong, but after this merges (we're working
on L->M upgrade) we can simply go with version=auto on every node and
just hit SIGHUP on conductors once we're done with all of compute
nodes right? Also, are there any other nice things that you guys plan
for M and we could use right away?


On 7 December 2015 at 08:47, Dan Smith  wrote:
>>> 1. Nova bootstrap will be called and it will perform db-migration. Since
>>> current approach to nova code is add-only we shouldn't need to stop
>>> services and old services should keep working on newer database. Also
>>> for minor version upgrades there will be no action here unless there is
>>> migration.
>>> 2. We upgrade all conductor at the same time. This should take mere
>>> seconds since we'll have prebuilt containers
>>> 3. We will upgrade rest of controller services with using "series: 1" in
>>> ansible to ensure rolling upgrades.
>
> Technically, 2 and 3 need to go at the same time. We have some machinery
> in place to help us not do online data conversions until all the control
> services are upgraded, but we haven't been through one of those yet to
> prove it out. Since the rest of the control services are mostly
> stateless, I would recommend just squashing those two steps together for
> the time being.
>
>>> 4. We will upgrade all of nova-compute services on it's own pace.
>
> Don't forget the final step of unpinning everyone's compute rpc version
> once you're done. If you're using version=auto for compute, you will
> soon be able to SIGHUP the services to get them to recalculate the
> version pin without restarting.
>
> https://review.openstack.org/#/c/253696/
>
> --Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [heat] Rico Lin for heat-core

[Thomas Herve]

On Mon, Dec 7, 2015 at 1:39 PM, Sergey Kraynev 
wrote:

>
> Hi all.
>
> I'd like to nominate Rico Lin for heat-core. He did awesome job with
> providing useful and valuable reviews. Also his contribution is really high
> [1] .
>
> [1] http://stackalytics.com/report/contribution/heat-group/60
>
> Heat core-team, please vote with:
>  +1 - if you agree
>   -1 - if you disagree
>
>
+1.

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

Re: [openstack-dev] [heat] Rico Lin for heat-core

[Peter Razumovsky]

+1

2015-12-07 15:39 GMT+03:00 Sergey Kraynev :

> Hi all.
>
> I'd like to nominate Rico Lin for heat-core. He did awesome job with
> providing useful and valuable reviews. Also his contribution is really high
> [1] .
>
> [1] http://stackalytics.com/report/contribution/heat-group/60
>
> Heat core-team, please vote with:
>  +1 - if you agree
>   -1 - if you disagree
>
> --
> Regards,
> Sergey.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting this week. The meeting is being held
Tuesday UTC1200.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

Re: [openstack-dev] [neutron][docs] Third Party Neutron Drivers

[Sean M. Collins]

Thanks for the advance notice. Sounds good to me.
-- 
Sean M. Collins

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

Re: [openstack-dev] [neutron][docs] Third Party Neutron Drivers

[Anita Kuno]

On 12/07/2015 10:17 AM, Sean M. Collins wrote:
> Thanks for the advance notice. Sounds good to me.
> 

I announced this at Monday's third party meeting.

Thanks Lana,
Anita.

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

[openstack-dev] [Fuel] Current Fuel CI status and issues related to CentOS7 migration

[Aleksandra Fedorova]

Hi everyone,

let me describe CI status and changes in CI caused by CentOS7
migration. Please read carefully as your local and custom test
environments might be affected as well.


* CentOS7 in docker with aufs on Ubuntu Trusty host is not stable

Containers of such type are required for Fuel ISO building process,
but this configuration is extremely sensitive to the versions of
kernel and docker packages.

ISO builds fail on 3.16 kernel or docker 1.6.1, see [1].

The current known-to-work configuration is:

  kernel 3.19
  docker 1.6.2

We have updated main build slaves to this configuration, so now
community build with CentOS7 is available at

   https://ci.fuel-infra.org/view/ISO/

* fuel-web is not compatible with python2.6

verify-fuel-web job, which was used to test fuel-web against python2.6
is now disabled. Work on cleaning up other jobs is currently in
progress in [2]

* fuel-library deployment tests have been refactored and now use
perestroika build scripts, see [3], to build fuel-library packages.

This is a huge step forward for Fuel CI, as we simplified job
configurations and configured deployment tests to use common template
[4]. This template can also be used for deployment tests for fuel-ostf
and other Fuel repositories.

* regression in upstream Ubuntu kernel 3.13.0-72 [5]

This issue is not related to CentOS7 merge but appeared in the same
timeframe and affected the testing process.

Deployment tests use external Ubuntu repository to install base OS on
OpenStack nodes. In nightly tests we use daily snapshots of
archive.ubuntu.com. You can find them at
http://mirror.fuel-infra.org/pkgs/

It appears that on 3rd of December new kernel was uploaded to
trusty-proposed repo which caused certain issues with LVM and leads to
Smoke failures.

For now to unblock CI we've pinned Ubuntu mirror used in tests to
known "good" snapshot with 3.13.0-71. See [6].

Please use this snapshot when running local or custom tests

  http://mirror.fuel-infra.org/pkgs/ubuntu-2015-12-02-170158/

or disable trusty-proposed repository till issue is resolved.


[1] https://bugs.launchpad.net/mos/+bug/1522788
[2] https://bugs.launchpad.net/fuel/+bug/1523514
[3] 
https://github.com/fuel-infra/jenkins-jobs/blob/a15c63461bddf857e0548d8b861bd4154e5f8f3a/servers/fuel-ci/builders/build-pkgs.sh#L59
[4] 
https://github.com/fuel-infra/jenkins-jobs/blob/a15c63461bddf857e0548d8b861bd4154e5f8f3a/servers/fuel-ci/build-and-test-pkgs.yaml
[5] https://bugs.launchpad.net/fuel/+bug/1523092
[6] 
https://github.com/fuel-infra/jenkins-jobs/commit/6745eef4964a8c365178953f5f5f45524bfeeb19

-- 
Aleksandra Fedorova
Fuel CI Team Lead
bookwar

__
OpenStack Development Mailing 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] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Anne Gentle]

On Mon, Dec 7, 2015 at 8:25 AM, Jeremy Stanley  wrote:

> On 2015-12-07 09:04:20 -0500 (-0500), Morgan Fainberg wrote:
> [...]
> > * We should not (regardless of free/non-free/etc) make sure that the docs
> > are fully self-contained when built locally. This would address the
> privacy
> > and security issues for the local docs. (Again Analytics can be enabled
> as
> > a build-time job).
>
> Assuming s/not// (looks like a typo?) I'm in complete agreement.
>
> > * We should ensure we are only loading any external sources via HTTPS
> > rather than HTTP.
>
> Or better yet, not loading any external sources at all (though
> figuring out how to find and link to locally installed distro
> packages of fonts and similar resources might get complicated, and
> so may still be easier left as distro-specific patches in their
> respective packaging).
>

Okay, this is helpful because even after logging the bugs for upstream I'm
not exactly sure how the offline use case becomes a reality. As an upstream
team our first priority is online.

Thanks,
Anne


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



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

Re: [openstack-dev] [TripleO] Summary of In-Progress TripleO Workflow and REST API Development

[Tzu-Mainn Chen]

- Original Message -
> On 12/07/2015 04:33 AM, Tzu-Mainn Chen wrote:
> > 
> >
> > On 04/12/15 23:04, Dmitry Tantsur wrote:
> >
> > On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote:
> >
> 
> >
> >
> > 5. In-Progress Development
> >
> > The initial spec for the tripleo-common library has already
> > been approved, and
> > various people have been pushing work forward.  Here's a
> > summary:
> >
> > * Move shared business logic out of CLI
> > * https://review.openstack.org/249134 - simple
> > validations (WIP)
> >
> >
> > When is this going to be finished? It's going to get me a huge
> > merge conflict in https://review.openstack.org/#/c/250405/ (and
> > make it impossible to backport to liberty btw).
> >
> > This plan would be fine if Mitaka development was the only
> > consideration but I hope that it can be adapted a little bit to take
> > into account the Liberty branches, and the significant backports
> > that will be happening there. The rdomanager-plugin->tripleoclient
> > transition made backports painful, and having moved on for that it
> > would be ideal if we didn't create the same situation again.
> >
> > What I would propose is the following:
> > - the tripleo_common repo is renamed to tripleo and consumed by Mitaka
> > - the tripleo_common repo continues to exist in Liberty
> > - the change to rename the package tripleo_common to tripleo occurs
> > on the tripleo repo in the master branch using oslo-style wildcard
> > imports[1], and initially no deprecation message
> > - this change is backported to the tripleo_common repo on the
> > stable/liberty branch
> >
> >
> > Heya - apologies for the bit of churn here.  I re-visited the
> > repo-renaming issue in IRC, and it sounds like
> > the vast majority of people are actually in favor of putting the
> > relevant library and API code in the
> > tripleo-common repository, and revisiting the creation of a tripleo
> > repository later, once code has had a
> > chance to settle.  I personally like this idea, as it reduces some
> > disruptive activity at a time when we're trying
> > to add quite a bit of new code.
> >
> > I double-checked with the people who originally raised objections to the
> > idea of putting API code into
> > tripleo-common.  One said that his objection had to do with package
> > naming, and he removed his objection
> > once it was realized that the package name could be independent of the
> > repo name.  The other clarified his
> > objection as simply a consistency issue that he thought was okay to
> > resolve until after the API code settled a
> > bit.
> >
> > So: I'm putting the idea of *not* creating a tripleo repo just quite yet
> > out there on the mailing list, and I'm
> > hopeful we can come to agreement in Tuesday's tripleo weekly IRC
> > meeting.  That would resolve a lot of the
> > concerns mentioned here, correct?
> 
> It does not seem to resolve mine concern, though. I'm still wondering
> where should I continue the major profiles refactoring. If it moves to
> triple-common/tripleo (whatever the name), how do I backport it?
> 

This part of the move is still pending; your concerns are resolved if your
PR goes in first, correct?  I think that should be fine.

Mainn

>
> >
> >
> > Mainn
> >
> >
> > Once this is in place, stable/liberty tripleoclient can gradually
> > move from the tripleo_common to the tripleo package, and parts of
> > then tripleoclient -> tripleo_common business logic move can also be
> > backported where appropriate.
> >
> > I'm planning on adding some liberty backportable commands as part of
> > blueprint tripleo-manage-software-deployments [2] and this approach
> > would greatly ease the backport process, and allow the business
> > logic to start in the tripleo repo.
> >
> > * https://review.openstack.org/228991 - deployment code
> > (ready for review)
> >
> > * Additional TripleO business logic
> > * rename tripleo-common repo to tripleo
> >   * https://review.openstack.org/#/c/249521/ (ready for
> > review)
> >   * https://review.openstack.org/#/c/249524/ (ready for
> > review)
> >   * https://review.openstack.org/#/c/247834/ (ready for
> > review)
> >
> > (here is my review comment on this change)
> >
> > I'd like to propose that we have a period where the tripleo_common
> > package continues to be usable without a deprecation message.
> >
> > Rather than using deprecated subclasses, can we just do oslo-style
> > wildcard imports [1] for this package transition?
> >
> > If we did that then the test files could just be moved to tripleo,
> >  

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

[Dan Smith]

> So Dan, correct me if I'm wrong, but after this merges (we're working
> on L->M upgrade) we can simply go with version=auto on every node and
> just hit SIGHUP on conductors once we're done with all of compute
> nodes right?

You need to hit all the nodes with SIGHUP. The api, conductor and
compute services all use the compute rpcapi. Scheduler should be
reasonably immune I think.

But, yes, that's the plan. So far the compute=auto is working in the
grenade tests:

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

> Also, are there any other nice things that you guys plan
> for M and we could use right away?

Nothing else you don't know of, AFAIK.

--Dan

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

Re: [openstack-dev] [TripleO] workflow

[Dougal Matthews]

On 7 December 2015 at 14:59, Dan Prince  wrote:

>
>
>
> On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:
> > On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
> > > On 23 November 2015 at 14:37, Dan Prince 
> > > wrote:
> > > > There are lots of references to "workflow" within TripleO
> > > > conversations
> > > > these days. We are at (or near) the limit of what we can do
> > > > within
> > > > Heat
> > > > with regards to upgrades. We've got a new TripleO API in the
> > > > works
> > > > (a
> > > > new version of Tuskar basically) that is specifically meant to
> > > > encapsulates business logic workflow around deployment. And, Lots
> > > > of
> > > > interest in using Ansible for this and that.
> > > >
> > > > So... Last week I spent a bit of time tinkering with the Mistral
> > > > workflow service that already exists in OpenStack and after a few
> > > > patches got it integrated into my undercloud:
> > > >
> > > > https://etherpad.openstack.org/p/tripleo-undercloud-workflow
> > > >
> > > > One could imagine us coming up with a set of useful TripleO
> > > > workflows
> > > > (something like this):
> > > >
> > > >  tripleo.deploy 
> > > >  tripleo.update 
> > > >  tripleo.run_ad_hoc_whatever_on_specific_roles <>
> > > >
> > > > Since Mistral (the OpenStack workflow service) can already
> > > > interact
> > > > w/
> > > > keystone and has a good many hooks to interact with core
> > > > OpenStack
> > > > services like Swift, Heat, and Nova we might get some traction
> > > > very
> > > > quickly here. Perhaps we add some new Mistral Ironic actions? Or
> > > > imagine smaller more focused Heat configuration stacks that we
> > > > drive
> > > > via Mistral? Or perhaps we tie in Zaqar (which already has some
> > > > integration into os-collect-config) to run ad-hoc deployment
> > > > snippets
> > > > on specific roles in an organized fashion?  Or wrapping mistral
> > > > w/
> > > > tripleoclient to allow users to more easily call TripleO specific
> > > > workflows (enhancing the user feedback like we do with our
> > > > heatclient
> > > > wrapping already)?
> > > >
> > > > Where all this might lead... I'm not sure. But I feel like we
> > > > might
> > > > benefit by adding a few extra options to our OpenStack deployment
> > > > tool
> > > > chain.
> > > I think this sounds promising. Lots of the code in the CLI is about
> > > managing workflows. For example when doing introspection we change
> > > the node state, poll for the result, start introspection, poll for
> > > the result, change the node state back and poll for the result. If
> > > mistral can help here I expect it could give us a much more robust
> > > solution.
> >
> > Hows this look:
> >
> > https://github.com/dprince/tripleo-mistral-
> > workflows/blob/master/tripleo/baremetal.yaml
>
> I made a short (13 minute) video demonstration that outlines what using
> Mistral might look like in TripleO. The demo uses the above workflow as
> an example.
>
> https://youtu.be/bnAT37O-sdw
>
>
That's really useful, Thanks! I can see this works really well in this
example.

I don't think it is correct to talk about it in direct competition with the
API. So far the code being written for the API is for template storage,
validation and deployment. I think out of this only the deployment code
could work well as a Minstral workflow. However, at the moment it is simply
calling the validation in the API and then starting the deploy. It might be
that a Minstral workflow could call the TripleO API for validation and then
deploy to Heat. This would require some investigation.

Having said that, I completely agree that it seems like a compelling option
as a replacement for the other code in the CLI. For the very workflow-y
bits like registration and introspection, the CLI has never been great.

I have one question at the moment, if the workflows are stored in the
Minstral database do you anticipate they are added during the undercloud
install? Since obviously we will want to version them etc. to match
everything else in TripleO.



>
> Dan
>
> >
> > >
> > > >  Dan
> > > >
> > > > _
> > > > __
> > > > ___
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > > su
> > > > bscribe
> > > > 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:unsu
> > > bs
> > > cribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

[Dougal Matthews]

On 2 December 2015 at 16:38, Emilien Macchi  wrote:

> Hi,
>
> I don't find any official statement on the Internet, but I've heard
> Tuskar is not going to be maintained anymore (tell me if I'm wrong).
>

I was hoping to raise this question at the TripleO meeting this week. The
question being; Should we officially deprecate Tuskar?

At the moment development has stalled, with the only activity being
proposal bot updating requirements, but these all fail CI as it is broken
for Tuskar.


>
> If I'm not wrong, I suggest we stop maintaining puppet-tuskar, and
> stable/liberty would be the latest release that we have maintained. I
> would also drop all the code in master and update the README explaining
> the module is not maintained anymore.
>
> Thanks for your help,
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Current Fuel CI status and issues related to CentOS7 migration

[Sergii Golovatiuk]

Hi,


On Mon, Dec 7, 2015 at 4:29 PM, Aleksandra Fedorova 
wrote:

> Hi everyone,
>
> let me describe CI status and changes in CI caused by CentOS7
> migration. Please read carefully as your local and custom test
> environments might be affected as well.
>
>
> * CentOS7 in docker with aufs on Ubuntu Trusty host is not stable
>
> Containers of such type are required for Fuel ISO building process,
> but this configuration is extremely sensitive to the versions of
> kernel and docker packages.
>
> ISO builds fail on 3.16 kernel or docker 1.6.1, see [1].
>
> The current known-to-work configuration is:
>
>   kernel 3.19
>   docker 1.6.2
>
> We have updated main build slaves to this configuration, so now
> community build with CentOS7 is available at
>
>https://ci.fuel-infra.org/view/ISO/


There are some plans to remove docker from master node completely. I think
we should force that action.

>
>
> * fuel-web is not compatible with python2.6
>
> verify-fuel-web job, which was used to test fuel-web against python2.6
> is now disabled. Work on cleaning up other jobs is currently in
> progress in [2]
>
> * fuel-library deployment tests have been refactored and now use
> perestroika build scripts, see [3], to build fuel-library packages.
>
> This is a huge step forward for Fuel CI, as we simplified job
> configurations and configured deployment tests to use common template
> [4]. This template can also be used for deployment tests for fuel-ostf
> and other Fuel repositories.
>
> * regression in upstream Ubuntu kernel 3.13.0-72 [5]
>
> This issue is not related to CentOS7 merge but appeared in the same
> timeframe and affected the testing process.
>
> Deployment tests use external Ubuntu repository to install base OS on
> OpenStack nodes. In nightly tests we use daily snapshots of
> archive.ubuntu.com. You can find them at
> http://mirror.fuel-infra.org/pkgs/
>
> It appears that on 3rd of December new kernel was uploaded to
> trusty-proposed repo which caused certain issues with LVM and leads to
> Smoke failures.
>
> For now to unblock CI we've pinned Ubuntu mirror used in tests to
> known "good" snapshot with 3.13.0-71. See [6].
>
> Please use this snapshot when running local or custom tests
>
>   http://mirror.fuel-infra.org/pkgs/ubuntu-2015-12-02-170158/
>
> or disable trusty-proposed repository till issue is resolved.
>

It's very dangerous to disable proposed, as it will break client's
deployments when package is moved from proposed to updates. There is a
standard process to block the package flow from proposed to updates, so
let's use it


>
>
> [1] https://bugs.launchpad.net/mos/+bug/1522788
> [2] https://bugs.launchpad.net/fuel/+bug/1523514
> [3]
> https://github.com/fuel-infra/jenkins-jobs/blob/a15c63461bddf857e0548d8b861bd4154e5f8f3a/servers/fuel-ci/builders/build-pkgs.sh#L59
> [4]
> https://github.com/fuel-infra/jenkins-jobs/blob/a15c63461bddf857e0548d8b861bd4154e5f8f3a/servers/fuel-ci/build-and-test-pkgs.yaml
> [5] https://bugs.launchpad.net/fuel/+bug/1523092
> [6]
> https://github.com/fuel-infra/jenkins-jobs/commit/6745eef4964a8c365178953f5f5f45524bfeeb19
>
> --
> Aleksandra Fedorova
> Fuel CI Team Lead
> bookwar
>
> __
> OpenStack Development Mailing 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] Documentation containing external resource links & privacy breaches

[Thomas Goirand]

On 12/04/2015 05:46 PM, Cory Benfield wrote:
> 
>> On 4 Dec 2015, at 13:20, Anne Gentle > > wrote:
>>
>> Great, thanks! This would work well for both oslosphinx and
>> openstackdocstheme:
>>
>> http://git.openstack.org/cgit/openstack/openstackdocstheme/
>>
>> Anne
> 
> Ok, so to begin with I’ve filed a change for openstackdocstheme
> here: https://review.openstack.org/#/c/253592/
> 
> This change initially leaves GA on by default, but I’d like feedback on
> that decision because I’m open to reversing that default.
> 
> One further question: does anyone know if oslosphinx pulls in
> openstackdocstheme periodically, or if they’re entirely separate and I
> need to file a separate change for that repository?
> 
> Cory

Cory,

Thanks a lot for this patch.

If I understand well, in Debian, I'd have to remove the:

[options]
analytics_tracking_code = UA-17511903-1

from the default theme.conf to make the GA code go away. Right? Would
there be a way so that I could set an environment variable instead of
patching the file, which is always a pain?

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [Neutron][DVR]

[Armando M.]

On 7 December 2015 at 05:41, Ryan Moats  wrote:

> "Armando M."  wrote on 12/04/2015 03:43:29 PM:
>
> > From: "Armando M." 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 12/04/2015 03:44 PM
> > Subject: Re: [openstack-dev] [Neutron][DVR]
> >
> > > On 4 December 2015 at 05:56, Ryan Moats  wrote:
> > > I pretty much agree with Oleg here - I'm not sure an additional tag
> > > for defects is needed.
> > > The idea of a DvrImpact in the commit message is interesting, but
> > > I'm not entirely convinced - if we
> > > do it for one sub-project, do we need to do it for all sub-projects
> > > and then what does that turn into?
> > What does this mean? No other project should care about this. DVR is
> > a core feature.
>
> I'm trying to understand if (at its logical conclusion) we end up with
> commit tags for all features (i.e. RbacImpact, BareMetalImpact, DbImpact,
>  etc.) and what that would do to the commit message...
>

Oh, you mean feature!

Well, even if we did have one per feature, we wouldn't have a single patch
impacting multiple features; patches are meant to be small and cohesive in
nature, and if they impacted more than one area they should be broken down.


>
>
> Ryan Moats (regXboi)
>
> __
> OpenStack Development Mailing 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] [Congress] Mid-cycle meet-up

[Tim Hinrichs]

Hi all,

We're having a mid-cycle meet-up January 26-28 in the Bay Area.

Here's a tentative schedule.  Comments, suggestions, questions?

Tue Jan 26: Discussion with Monasca team about integration.
- Intro to Congress (slides or whiteboard)
- Intro to Monasca (slides or whiteboard)
- Design discussion
- Prototyping

Wed Jan 27: Congress team code sprint for distributed arch

Thu Jan 28: Congress team design session for high availability and high
throughput

More logistics details will follow.

I hope everyone can make it!

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

Re: [openstack-dev] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

[Thomas Goirand]

On 12/07/2015 03:04 PM, Morgan Fainberg wrote:
> Lets keep the accusations/defence of wording choices
> out of the rest of the thread and focus on getting the docs to a place
> that works for all the parties.

Yes please.

> I did see the earlier comment that the
> external resources (due to national firewalls) are a real impact, that
> alone should be enough to encourage the changes.

Yup.

> So in short, I think Anne's summary is good, but is missing two items,
> below I've tried to cover the things we should target to get the docs
> theme in shape:
> 
> 1) CDN is not useful for local browsing (and may actually be a
> detriment). This can be enabled as a build-time job (as I described above)
> 2) Non Minified JS (actively being worked on).
> 
> The additional points are (as outlined by Thomas):
> 
> * We should not (regardless of free/non-free/etc) make sure that the
> docs are fully self-contained when built locally. This would address the
> privacy and security issues for the local docs. (Again Analytics can be
> enabled as a build-time job).
> * We should ensure we are only loading any external sources via HTTPS
> rather than HTTP.

Thanks for this very accurate recap.

>> * We should ensure we are only loading any external sources via HTTPS
>> rather than HTTP.
>
> Or better yet, not loading any external sources at all (though
> figuring out how to find and link to locally installed distro
> packages of fonts and similar resources might get complicated, and
> so may still be easier left as distro-specific patches in their
> respective packaging).

Most of the time, this is handled by removing the 3rdparty static
content (the font in this case), and replacing it by a symlink to the
distro's system file. Though currently, the theme doesn't include a
local copy of the font, and has no mechanism to use one. I'm not sure if
there's a way to check if a local content is present in Javascript. Any
suggestion?

By the way, why do we absolutely need a specific font? Can't we just use
what's in the system already? As far I as I remember, the awesome font
is very close from the system ones (like DejaVu, for example). Maybe
there could be such a fallback at least?

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] [mistral] bugfix for "Fix concurrency issues by using READ_COMMITTED" unveils / creates a different bug

[ELISHA, Moshe (Moshe)]

Hi all,

The current bugfix I am working on[1] have unveiled / created a bug.
Test "WorkflowResumeTest.test_resume_different_task_states" sometimes fails 
because "task4" is executed twice instead of once (See unit test output and 
workflow below).

This happens because task2 on-complete is running task4 as expected but also 
task3 executes task4 by mistake.

It is not consistent but it happens quite often - This happens if the unit test 
resumes the WF and updates action execution of task2 and finishes task2 before 
task3 is finished.
Scenario:


1.   Task2 in method on_action_complete - changes task2 state to RUNNING.

2.   Task3 in method on_action_complete - changes task2 state to RUNNING 
(before task2 calls _on_task_state_change).

3.   Task3 in "_on_task_state_change" > "continue_workflow" > 
"DirectWorkflowController ._find_next_commands" - it finds task2 because task2 
is in SUCCESS and processed = False and "_find_next_commands_for_task(task2)" 
returns task4.

4.   Task3 executes command to RunTask task4.

5.   Task2 in "_on_task_state_change" > "continue_workflow" > 
"DirectWorkflowController ._find_next_commands" - it finds task2 because task2 
is in SUCCESS and processed = False and "_find_next_commands_for_task(task2)" 
returns task4.

6.   Task2 executes command to RunTask task4.


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


If I am not mistaken - this issue also exists in the current code and my bugfix 
only made it much more often. Can you confirm?
I don't have enough knowledge on how to fix this issue...
For now - I have modified the test_resume_different_task_states unit test to 
wait for task3 to be processed before updating the action execution of task2.
If you agree this bug exist today as well - we can proceed with my bugfix and 
open a different bug for that issue.

Thanks.



[stack@melisha-devstack mistral(keystone_admin)]$ tox -e py27 -- 
WorkflowResumeTest.test_resume_different_task_states
...
==
FAIL: 
mistral.tests.unit.engine.test_workflow_resume.WorkflowResumeTest.test_resume_different_task_states
tags: worker-0
--
pythonlogging:'': {{{WARNING [oslo_db.sqlalchemy.utils] Id not in sort_keys; is 
sort_keys unique?}}}
stderr: {{{
/opt/stack/mistral/.tox/py27/local/lib/python2.7/site-packages/novaclient/v2/client.py:109:
 UserWarning: 'novaclient.v2.client.Client' is not designed to be initialized 
directly. It is inner class of novaclient. Please, use 
'novaclient.client.Client' instead. Related lp bug-report: 1493576
  _LW("'novaclient.v2.client.Client' is not designed to be "
}}}

stdout: {{{
Engine test case exception occurred: 4 != 5
Exception type: 

Printing workflow executions...

wb.wf1 [state=SUCCESS, output={u'__execution': {u'params': {}, u'id': 
u'2807dd99-ca6f-49d7-886d-7d3b79e1c49e', u'spec': {u'type': u'direct', u'name': 
u'wf1', u'tasks': {u'task4': {u'type': u'direct', u'name': u'task4', 
u'version': u'2.0', u'action': u'std.echo output="Task 4"'}, u'task2': 
{u'type': u'direct', u'name': u'task2', u'on-complete': [u'task4'], u'version': 
u'2.0', u'action': u'std.mistral_http url="http://google.com";'}, u'task3': 
{u'type': u'direct', u'name': u'task3', u'version': u'2.0', u'action': 
u'std.echo output="Task 3"'}, u'task1': {u'type': u'direct', u'name': u'task1', 
u'on-complete': [u'task3', u'pause'], u'version': u'2.0', u'action': u'std.echo 
output="Hi!"'}}, u'version': u'2.0'}, u'input': {}}, u'task4': u'Task 4', 
u'task3': u'Task 3', u'__tasks': {u'848c6e92-b1b1-4d54-b11d-c93cfb4fc88f': 
u'task2', u'00a546e7-8da9-4603-b6be-54d58b14c625': u'task1'}}]
 task2 [id=848c6e92-b1b1-4d54-b11d-c93cfb4fc88f, state=SUCCESS, 
published={}]
 task1 [id=00a546e7-8da9-4603-b6be-54d58b14c625, state=SUCCESS, 
published={}]
 task3 [id=8ce20324-7fba-4424-bcd2-1e0c9b27fd4a, state=SUCCESS, 
published={}]
 task4 [id=3758de43-9bc3-4ac9-b3f3-29eb543b16ef, state=SUCCESS, 
published={}]
 task4 [id=f12ee464-0ba5-48c7-8423-9f425a00e675, state=SUCCESS, 
published={}]
}}}

Traceback (most recent call last):
  File "mistral/tests/unit/engine/test_workflow_resume.py", line 321, in 
test_resume_different_task_states
self.assertEqual(4, len(wf_ex.task_executions))
  File 
"/opt/stack/mistral/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 350, in assertEqual
self.assertThat(observed, matcher, message)
  File 
"/opt/stack/mistral/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 435, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 4 != 5
Ran 1 tests in 15.517s (+2.591s)
FAILED (id=301, failures=1 (+1))
error: testr failed (1)
ERROR: InvocationError: '/opt/stack/mistral/.tox/py27/bin/python setup.py testr 
--slowest --testr-args=WorkflowResumeTest.test_resume_different_task_states'
___

[openstack-dev] [horizon] Updated High Definition Logo for Alternate Theme

[Diana Whitten]

Hi All,

I am currently working on updating the OpenStack logo being used in the
*alternate* theme of Horizon to show that Horizon can easily support both
PNG and SVG logos.

I have found the correct logo assets for our Splash screen, however, I do
not see a corresponding high definition asset to replace our current top
nav .png, as seen in the top left corner here:
https://www.dropbox.com/s/20xw1bvim4sv629/Screenshot%202015-11-21%2014.54.57.png?dl=0

I've used the High Definition assets given on the
http://www.openstack.org/brand/openstack-logo/ site to replace the matching
logo on our Splash page, but I was unable to find a logo that matches the
Horizontal logo used in our Top Nav on the public site.

I've been provided an asset for the horizontal logo, but I was wondering
who I need to get permission from to update / use it?

I only ask because the ‘Terms and Conditions’ state: "You agree that you
will not (i) alter or modify the OpenStack Logo as provided by the
OpenStack Foundation;"

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

[openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Alexey Elagin]

Hello all,

We have a security problem in Fuel 7.0. It's related to plugin
development and allows to execute code in mcollective docker container
on Fuel master node. Any fuel plugin may contains a yaml file with
deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
an ability to run some code on node with role "master". It's also
possible to connect to any target node via ssh without a password from
within the container.

As i understood, it was made to simplify some deployment cases. I see
some steps for resolving this situation:
 1. Fuel team should disallow
execution of any puppet manifests or bash code on nodes with master
role.
 2. Append the Fuel documentation. Notify users about this
security issue.

What do you think about it? What deployment cases which require
execution of code on role "master" do you know?

-- 
Best regards,
 Alexey
 Deployment Engineer
 Mirantis, Inc
 Cell: +7 (968) 880 2288
 Skype: shikelbober
 Slack: aelagin
 mailto:aela...@mirantis.com


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

[openstack-dev] [glance] Add Ian Cordasco back into glance-core

[Flavio Percoco]

Greetings,

Not long ago, Ian Cordasco, sent an email out stepping down from his
core roles as he didn't have the time to dedicate to the project
team's he was part of.

Ian has contacted me mentioning that he's gotten clearance, and
therefore, time to dedicate to Glance and other activities around our
community (I'll let him expand on this and answer questions if there
are).

As it was mentioned in the "goodbye thread" - and because Ian knows
Glance quite well already, including the processes we follow - I'd
like to propose a fast-track addition for him to join the team again.

Please, just like for every other folk volunteering for this role, do
provide your feedback on this. If no rejections are made, I'll proceed
to adding Ian back to our core team in a week from now.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [release][all] bugs will now close automatically when patches merge

[Doug Hellmann]

As mentioned previously [1], as part of deprecating our use of Launchpad
for tracking completed work we have changed the default behavior so that
when a patch with "Fixes-Bug" in the commit message merges the bug will
move to "Fix Released" (a closed state) instead of "Fix Committed" (a
"still open" state).

The patch to make this change [2] has merged, and the behavior change
should be in effect by now.

As part of the M1 tagging process, we manually closed all "fix
committed" bugs. If your project has more than a few such bugs left
this week, drop by #openstack-release and let me know and I can use
the script to batch update them for you. If you just have a few, please
go ahead and close them manually.

Thanks,
Doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-November/080288.html
[2] https://review.openstack.org/248922

__
OpenStack Development Mailing 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] Mistral team meeting minutes - 12/07/2015

[Nikolay Makhotkin]

Hi,

Thank you for coming us today!

Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-12-07-15.59.html

Log:
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-12-07-15.59.log.html


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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Roman Prykhodchenko]

Alexey,

thank you for bringing this up. IMO discussing security problems is better to 
be done in a special kind of Launchpad bugs.

- romcheg


> 7 груд. 2015 р. о 17:36 Alexey Elagin  написав(ла):
> 
> Hello all,
> 
> We have a security problem in Fuel 7.0. It's related to plugin
> development and allows to execute code in mcollective docker container
> on Fuel master node. Any fuel plugin may contains a yaml file with
> deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
> an ability to run some code on node with role "master". It's also
> possible to connect to any target node via ssh without a password from
> within the container.
> 
> As i understood, it was made to simplify some deployment cases. I see
> some steps for resolving this situation:
> 1. Fuel team should disallow
> execution of any puppet manifests or bash code on nodes with master
> role.
> 2. Append the Fuel documentation. Notify users about this
> security issue.
> 
> What do you think about it? What deployment cases which require
> execution of code on role "master" do you know?
> 
> --
> Best regards,
> Alexey
> Deployment Engineer
> Mirantis, Inc
> Cell: +7 (968) 880 2288
> Skype: shikelbober
> Slack: aelagin
> mailto:aela...@mirantis.com
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Javeria Khan]

My two cents. It would be useful to have a role that could execute on the
Fuel Master host itself rather than a container.

--
Javeria
On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko"  wrote:

> Alexey,
>
> thank you for bringing this up. IMO discussing security problems is better
> to be done in a special kind of Launchpad bugs.
>
> - romcheg
>
>
> > 7 груд. 2015 р. о 17:36 Alexey Elagin 
> написав(ла):
> >
> > Hello all,
> >
> > We have a security problem in Fuel 7.0. It's related to plugin
> > development and allows to execute code in mcollective docker container
> > on Fuel master node. Any fuel plugin may contains a yaml file with
> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
> > an ability to run some code on node with role "master". It's also
> > possible to connect to any target node via ssh without a password from
> > within the container.
> >
> > As i understood, it was made to simplify some deployment cases. I see
> > some steps for resolving this situation:
> > 1. Fuel team should disallow
> > execution of any puppet manifests or bash code on nodes with master
> > role.
> > 2. Append the Fuel documentation. Notify users about this
> > security issue.
> >
> > What do you think about it? What deployment cases which require
> > execution of code on role "master" do you know?
> >
> > --
> > Best regards,
> > Alexey
> > Deployment Engineer
> > Mirantis, Inc
> > Cell: +7 (968) 880 2288
> > Skype: shikelbober
> > Slack: aelagin
> > mailto:aela...@mirantis.com
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing 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] [glance] Add Ian Cordasco back into glance-core

[Nikhil Komawar]

+2

Great to see this happen.

On 12/7/15 11:36 AM, Flavio Percoco wrote:
> Greetings,
>
> Not long ago, Ian Cordasco, sent an email out stepping down from his
> core roles as he didn't have the time to dedicate to the project
> team's he was part of.
>
> Ian has contacted me mentioning that he's gotten clearance, and
> therefore, time to dedicate to Glance and other activities around our
> community (I'll let him expand on this and answer questions if there
> are).
>
> As it was mentioned in the "goodbye thread" - and because Ian knows
> Glance quite well already, including the processes we follow - I'd
> like to propose a fast-track addition for him to join the team again.
>
> Please, just like for every other folk volunteering for this role, do
> provide your feedback on this. If no rejections are made, I'll proceed
> to adding Ian back to our core team in a week from now.
>
> Cheers,
> Flavio
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil

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

Re: [openstack-dev] [Openstack-operators] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Dina Belova]

Sylvain,

in fact we just used the same practice LDT team is having - they do have
their meeting on openstack-operators channel, for instance. We were
choosing the time slot available for different people from different
company, due to the Doodle vote it was chosen 15:00 UTC Tuesdays (and as
you can see it's pretty busy slot on the official channels). And although
we're moving the meeting +1 hour, it's still busy because it's comfortable
time for almost all US and European folks at the same time. Therefore we're
just continuing to use Large Deployment Team's practice, as its sub team in
fact.

Although, if there will be a wish from contributors to move to some
official channel, we can do that as well.

You should also provide a YAML file here
> http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/


Thanks for the link ^^, will do.

Cheers,
Dina

On Mon, Dec 7, 2015 at 2:19 PM, Sylvain Bauza  wrote:

>
>
> Le 07/12/2015 11:27, Dina Belova a écrit :
>
> Ok, so due to the responses I propose to finalise this decision and move
> the meeting to *16:00 UTC (Tuesdays)*.
> So tomorrow please join me *on #openstack-performance at 16:00 UTC.*
>
>
> Why are you not using the meeting channels?
> You should also provide a YAML file here
> http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/
>
> -Sylvain
>
> Cheers, Dina
>
> P.S.
> Ryan, I'm suggesting you to come as usually at 15:00, I'll be online -
> let's prepare possible questions you're interested in to be covered during
> the meeting time. I'll be happy to make everything possible for you to
> participate at least in this way..
>
> On Sat, Dec 5, 2015 at 2:12 AM, Clint Byrum  wrote:
>
>> Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
>> > Dear performance folks,
>> >
>> > There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
>> > )
>> to
>> > 16:00 UTC (also Tuesdays
>> > )
>> to
>> > make them more comfortable for US guys.
>> >
>> > Please leave your +1 / -1 here in the email thread.
>> >
>> > Btw +1 from me :)
>>
>> +1, this makes it actually possible for me to participate. :)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>
> ___
> OpenStack-operators mailing 
> listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>


-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
__
OpenStack Development Mailing 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] Documentation containing external resource links & privacy breaches

[Cory Benfield]

> On 7 Dec 2015, at 16:10, Thomas Goirand  wrote:
> 
> Cory,
> 
> Thanks a lot for this patch.
> 
> If I understand well, in Debian, I'd have to remove the:
> 
> [options]
> analytics_tracking_code = UA-17511903-1
> 
> from the default theme.conf to make the GA code go away. Right? Would
> there be a way so that I could set an environment variable instead of
> patching the file, which is always a pain?

You don’t need to remove that, you set it in `html_theme_options` in the 
conf.py for the relevant docs. That’s a fairly simple patch, but if the docs 
theme people are open to having an environment variable we could set up the 
default conf.py appropriately.

NB: You’d want html_theme_options to be set to:

html_theme_options = {
‘analytics_tracking_code’: ‘'
}

Cory


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

Re: [openstack-dev] [glance] Auth_version from 'old style' URLs in the database

[Brant Knudson]

On Thu, Dec 3, 2015 at 10:24 AM, Bunting, Niall 
wrote:

> Hi,
>
> Currently glance will use an auth_url if in the database. Eg.
> 10.0.0.8:5000/v2.0
>
> However glance currently takes the auth_version from the config
> files. Therefore this can lead to a mismatch of keystone version to be used
> between the url and the config files. This is problematic due to a
> different
> resource id being required in different version of keystone (in keystone v2
> it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).
>
> Using a v2 url and config file with keystone v3:
> 10.0.0.8:5000/v2.0/auth/tokens -- Fails to authenticate the user,
> and user can't download image.
>
> See https://bugs.launchpad.net/glance-store/+bug/1507610 for a bug report
> on this.
>
> This means that the fix proposed by
> https://review.openstack.org/#/c/238074/ parses the URL for an
> auth_version
> and then if found will use the parsed value as the auth_version rather than
> the one from the config files. Taking the url as the true source.
> Therefore the image will still work as the auth_version used by glance is
> the
> one defined in the URL meaning the correct resource id appended.
>
> Whilst discussing it with Kairat it was proposed that we ignore the
> keystone version in the URL and if it does not support the auth_version
> in the configs, then the image would fail to be downloaded. This is due to
> a
> preference to have a centralised auth_version value.
>
> I am wondering what people would prefer to do, to support the 'old style'
> urls
> and therefore parse the version from the url. Or to make the auth_version
> common and potentially break the 'old style' database entries.
>
> Thanks,
> Niall Bunting
>
>
If you want to know the version supported by the auth_url, do a GET on it
and the JSON returned will tell you what version(s) are supported. This is
preferred since parsing the value is error-prone and may not support all
deployment options (maybe somebody puts keystone v2 on /v2_old or
something). The keystoneauth library provides functions for getting the
version of the service[1].

Also, the keystoneauth library provides functions for all this stuff.
Glance shouldn't have to deal with this at all since you can just point
keystoneauth to the config section and it'll load the correct plugin and
create a session that your app can use to do its operations without
worrying about the specifics of authentication.

[1]
http://docs.openstack.org/developer/keystoneauth/api/keystoneauth1.html#module-keystoneauth1.discover

- Brant



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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Eugene Korekin]

As far as I know this feature is planned for the next releases.

But I think the main problem is: it's not obvious that just by 
installing a plugin, even without enabling the plugin in Fuel user could 
break or somehow alter already existing environments.  It could be done 
by malicious attacker who could compromise plugin or just 
unintentionally with some bug in the plugin code.


Unfortunately, by installing some plugin a user jeopardizes his existing 
environments. And I think we should at least document these risks.


On 07.12.2015 19:52, Javeria Khan wrote:


My two cents. It would be useful to have a role that could execute on 
the Fuel Master host itself rather than a container.


--
Javeria

On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" > wrote:


Alexey,

thank you for bringing this up. IMO discussing security problems
is better to be done in a special kind of Launchpad bugs.

- romcheg


> 7 груд. 2015 р. о 17:36 Alexey Elagin mailto:aela...@mirantis.com>> написав(ла):
>
> Hello all,
>
> We have a security problem in Fuel 7.0. It's related to plugin
> development and allows to execute code in mcollective docker
container
> on Fuel master node. Any fuel plugin may contains a yaml file with
> deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and
there is
> an ability to run some code on node with role "master". It's also
> possible to connect to any target node via ssh without a
password from
> within the container.
>
> As i understood, it was made to simplify some deployment cases.
I see
> some steps for resolving this situation:
> 1. Fuel team should disallow
> execution of any puppet manifests or bash code on nodes with master
> role.
> 2. Append the Fuel documentation. Notify users about this
> security issue.
>
> What do you think about it? What deployment cases which require
> execution of code on role "master" do you know?
>
> --
> Best regards,
> Alexey
> Deployment Engineer
> Mirantis, Inc
> Cell: +7 (968) 880 2288 
> Skype: shikelbober
> Slack: aelagin
> mailto:aela...@mirantis.com 
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


--
Eugene Korekin
Partner Enablement Team Deployment Engineer

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

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

[Carl Baldwin]

On Fri, Dec 4, 2015 at 12:22 PM, Henry Gessau  wrote:
> 1. RFE: "I want X"
> 2. Spec: "I plan to implement X like this"
> 3. devref: "How X is implemented and how to extend it"
> 4. OS docs: "API and guide for using X"
>
> Once X is implemented I don't want to have to go to 1 or 2 to find information
> on it. The devref may have a lot of content from the spec, but the spec is not
> maintained and the implementation may differ in some ways. The devref should
> be kept current with refactorings, etc. of the implementation.

Henry, I was also impressed by how clearly you communicated this.
This ought to be included somewhere prominently in our
doc/source/policies/ or somewhere like that.

Carl

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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Andrew Woodward]

I'd have to say that this is expected behavior. I'm not sure what you would
hope to prohibit when these kinds of things are necessary for the
deployment. We also can't prohibit this from being done in a plugin, this
is what the plugin verification is supposed to help combat. If you just go
download a random puppet manifest // script // etc... from the internet,
how do you ensure that it didn't install a root-kit.

On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin  wrote:

> As far as I know this feature is planned for the next releases.
>
> But I think the main problem is: it's not obvious that just by installing
> a plugin, even without enabling the plugin in Fuel user could break or
> somehow alter already existing environments.  It could be done by malicious
> attacker who could compromise plugin or just unintentionally with some bug
> in the plugin code.
>
> Unfortunately, by installing some plugin a user jeopardizes his existing
> environments. And I think we should at least document these risks.
>
>
> On 07.12.2015 19:52, Javeria Khan wrote:
>
> My two cents. It would be useful to have a role that could execute on the
> Fuel Master host itself rather than a container.
>
> --
> Javeria
> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko"  wrote:
>
>> Alexey,
>>
>> thank you for bringing this up. IMO discussing security problems is
>> better to be done in a special kind of Launchpad bugs.
>>
>> - romcheg
>>
>>
>> > 7 груд. 2015 р. о 17:36 Alexey Elagin 
>> написав(ла):
>> >
>> > Hello all,
>> >
>> > We have a security problem in Fuel 7.0. It's related to plugin
>> > development and allows to execute code in mcollective docker container
>> > on Fuel master node. Any fuel plugin may contains a yaml file with
>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
>> > an ability to run some code on node with role "master". It's also
>> > possible to connect to any target node via ssh without a password from
>> > within the container.
>> >
>> > As i understood, it was made to simplify some deployment cases. I see
>> > some steps for resolving this situation:
>> > 1. Fuel team should disallow
>> > execution of any puppet manifests or bash code on nodes with master
>> > role.
>> > 2. Append the Fuel documentation. Notify users about this
>> > security issue.
>> >
>> > What do you think about it? What deployment cases which require
>> > execution of code on role "master" do you know?
>> >
>> > --
>> > Best regards,
>> > Alexey
>> > Deployment Engineer
>> > Mirantis, Inc
>> > Cell: +7 (968) 880 2288
>> > Skype: shikelbober
>> > Slack: aelagin
>> > mailto:aela...@mirantis.com
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Eugene Korekin
> Partner Enablement Team Deployment Engineer
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

[Miles Gould]

I also vote for baremetal-inspection - punning names are fun, but increase the 
amount of stuff new developers have to learn.

I'm totally in for the Peter Sellers marathon, though.

Miles

- Original Message -
> From: "Jay Pipes" 
> To: openstack-dev@lists.openstack.org
> Sent: Saturday, 5 December, 2015 2:53:17 PM
> Subject: Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for 
> a subproject (ironic-inspector in this
> case)
> 
> On 12/04/2015 04:45 PM, Dmitry Tantsur wrote:
> > 1. "baremetalintrospection" - named after the process we
> > implement
> > 2. "baremetalinspector" - using our code name after the
> > official ironic project name.
> 
> baremetal-inspection is my vote.
> 
> I believe Pavlo will soon be proposing a hardware-composition service
> endpoint as well...
> 
> Best,
> -jay
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [glance] Auth_version from 'old style' URLs in the database

[Clint Byrum]

Excerpts from Flavio Percoco's message of 2015-12-04 07:00:53 -0800:
> On 03/12/15 16:24 +, Bunting, Niall wrote:
> >Hi,
> >
> >Currently glance will use an auth_url if in the database. Eg. 
> >10.0.0.8:5000/v2.0
> >
> >However glance currently takes the auth_version from the config
> >files. Therefore this can lead to a mismatch of keystone version to be used
> >between the url and the config files. This is problematic due to a different
> >resource id being required in different version of keystone (in keystone v2
> >it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).
> >
> >Using a v2 url and config file with keystone v3:
> >10.0.0.8:5000/v2.0/auth/tokens -- Fails to authenticate the user,
> >and user can't download image.
> >
> >See https://bugs.launchpad.net/glance-store/+bug/1507610 for a bug report
> >on this.
> >
> >This means that the fix proposed by
> >https://review.openstack.org/#/c/238074/ parses the URL for an auth_version
> >and then if found will use the parsed value as the auth_version rather than
> >the one from the config files. Taking the url as the true source.
> >Therefore the image will still work as the auth_version used by glance is the
> >one defined in the URL meaning the correct resource id appended.
> >
> >Whilst discussing it with Kairat it was proposed that we ignore the
> >keystone version in the URL and if it does not support the auth_version
> >in the configs, then the image would fail to be downloaded. This is due to a
> >preference to have a centralised auth_version value.
> >
> >I am wondering what people would prefer to do, to support the 'old style' 
> >urls
> >and therefore parse the version from the url. Or to make the auth_version
> >common and potentially break the 'old style' database entries.
> >
>
> To clarify a bit the problem, this seems to be related only to the
> swift driver. Right?
>
> My opinion is that, whatever we do, we must not break users of this
> code.
>
> I don't believe this information should be stored in the database,
> therefore I'd prefer going with `auth_version` and write the proper
> migrations to remove this info from the DB.
>
> I don't really know why it was put there in the first place but I'll
> let folks that know this info chime in and provide some insights.
>

I agree with everything Flavio says above. These urls are not state,
they are config, which may change regardless of user action. Config
belongs in a place where operators can change it.

What may be important is to have a way to report to the operators what
urls are going to be removed before db migrations are run, so they can
be certain the config covers them all.

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

Re: [openstack-dev] [glance] Add Ian Cordasco back into glance-core

[Bhandaru, Malini K]

+1  ☺

From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
Sent: Monday, December 07, 2015 8:55 AM
To: Flavio Percoco ; OpenStack Development Mailing List (not 
for usage questions) 
Subject: Re: [openstack-dev] [glance] Add Ian Cordasco back into glance-core

+2

Great to see this happen.
On 12/7/15 11:36 AM, Flavio Percoco wrote:
Greetings,

Not long ago, Ian Cordasco, sent an email out stepping down from his
core roles as he didn't have the time to dedicate to the project
team's he was part of.

Ian has contacted me mentioning that he's gotten clearance, and
therefore, time to dedicate to Glance and other activities around our
community (I'll let him expand on this and answer questions if there
are).

As it was mentioned in the "goodbye thread" - and because Ian knows
Glance quite well already, including the processes we follow - I'd
like to propose a fast-track addition for him to join the team again.

Please, just like for every other folk volunteering for this role, do
provide your feedback on this. If no rejections are made, I'll proceed
to adding Ian back to our core team in a week from now.

Cheers,
Flavio





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--



Thanks,

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

[openstack-dev] ML2 TypeManager question

[Sławek Kapłoński]

Hello,

Recently I was checking something in code of ML2 Type manager 
(neutron.plugins.ml2.managers) and I found in TypeManager class in method 
create_network_segments that to this method as argument is passed "tenant_id" 
but I can't find where it is used.
Can someone more experienced explain me why this tenant_id is passed there and 
where it is used? Thx in advance :)

--
Pozdrawiam / Best regards
Sławek Kapłoński
sla...@kaplonski.pl

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

Re: [openstack-dev] [glance] Add Ian Cordasco back into glance-core

[Louis Taylor]

On Mon, Dec 07, 2015 at 12:06:03PM -0430, Flavio Percoco wrote:
> Greetings,
> 
> Not long ago, Ian Cordasco, sent an email out stepping down from his
> core roles as he didn't have the time to dedicate to the project
> team's he was part of.
> 
> Ian has contacted me mentioning that he's gotten clearance, and
> therefore, time to dedicate to Glance and other activities around our
> community (I'll let him expand on this and answer questions if there
> are).
> 
> As it was mentioned in the "goodbye thread" - and because Ian knows
> Glance quite well already, including the processes we follow - I'd
> like to propose a fast-track addition for him to join the team again.
> 
> Please, just like for every other folk volunteering for this role, do
> provide your feedback on this. If no rejections are made, I'll proceed
> to adding Ian back to our core team in a week from now.

+1! It would be great to have Ian back.

Louis


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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Stanislaw Bogatkin]

+1 to Andrew. Plugins created for run some code and plugin verification is
the source of trust there.

On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward  wrote:

> I'd have to say that this is expected behavior. I'm not sure what you
> would hope to prohibit when these kinds of things are necessary for the
> deployment. We also can't prohibit this from being done in a plugin, this
> is what the plugin verification is supposed to help combat. If you just go
> download a random puppet manifest // script // etc... from the internet,
> how do you ensure that it didn't install a root-kit.
>
> On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin 
> wrote:
>
>> As far as I know this feature is planned for the next releases.
>>
>> But I think the main problem is: it's not obvious that just by installing
>> a plugin, even without enabling the plugin in Fuel user could break or
>> somehow alter already existing environments.  It could be done by malicious
>> attacker who could compromise plugin or just unintentionally with some bug
>> in the plugin code.
>>
>> Unfortunately, by installing some plugin a user jeopardizes his existing
>> environments. And I think we should at least document these risks.
>>
>>
>> On 07.12.2015 19:52, Javeria Khan wrote:
>>
>> My two cents. It would be useful to have a role that could execute on the
>> Fuel Master host itself rather than a container.
>>
>> --
>> Javeria
>> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko"  wrote:
>>
>>> Alexey,
>>>
>>> thank you for bringing this up. IMO discussing security problems is
>>> better to be done in a special kind of Launchpad bugs.
>>>
>>> - romcheg
>>>
>>>
>>> > 7 груд. 2015 р. о 17:36 Alexey Elagin < 
>>> aela...@mirantis.com> написав(ла):
>>> >
>>> > Hello all,
>>> >
>>> > We have a security problem in Fuel 7.0. It's related to plugin
>>> > development and allows to execute code in mcollective docker container
>>> > on Fuel master node. Any fuel plugin may contains a yaml file with
>>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
>>> > an ability to run some code on node with role "master". It's also
>>> > possible to connect to any target node via ssh without a password from
>>> > within the container.
>>> >
>>> > As i understood, it was made to simplify some deployment cases. I see
>>> > some steps for resolving this situation:
>>> > 1. Fuel team should disallow
>>> > execution of any puppet manifests or bash code on nodes with master
>>> > role.
>>> > 2. Append the Fuel documentation. Notify users about this
>>> > security issue.
>>> >
>>> > What do you think about it? What deployment cases which require
>>> > execution of code on role "master" do you know?
>>> >
>>> > --
>>> > Best regards,
>>> > Alexey
>>> > Deployment Engineer
>>> > Mirantis, Inc
>>> > Cell: +7 (968) 880 2288
>>> > Skype: shikelbober
>>> > Slack: aelagin
>>> > mailto:aela...@mirantis.com
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>> Eugene Korekin
>> Partner Enablement Team Deployment Engineer
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

[Sean M. Collins]

On Mon, Dec 07, 2015 at 12:18:29PM EST, Carl Baldwin wrote:
> On Fri, Dec 4, 2015 at 12:22 PM, Henry Gessau  wrote:
> > 1. RFE: "I want X"
> > 2. Spec: "I plan to implement X like this"
> > 3. devref: "How X is implemented and how to extend it"
> > 4. OS docs: "API and guide for using X"
> >
> > Once X is implemented I don't want to have to go to 1 or 2 to find 
> > information
> > on it. The devref may have a lot of content from the spec, but the spec is 
> > not
> > maintained and the implementation may differ in some ways. The devref should
> > be kept current with refactorings, etc. of the implementation.
> 
> Henry, I was also impressed by how clearly you communicated this.
> This ought to be included somewhere prominently in our
> doc/source/policies/ or somewhere like that.
> 

+1 for Henry's great answer, and +1 for Carl's suggestion!

-- 
Sean M. Collins

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

[openstack-dev] [Infra] Meeting Tuesday December 8th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday December 8th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-01-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-01-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-01-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] [Manila] Tempest scenario tests vs. gate condition

[Ben Swartzlander]

On 12/03/2015 06:38 AM, John Spray wrote:

Hi,

We're working towards getting the devstack/CI parts ready to test the
forthcoming ceph native driver, and have a question: will a driver be
accepted into the tree if it has CI for running the api/ tempest
tests, but not the scenario/ tempest tests?

The context is that because the scenario tests require a client to
mount the shares, that's a bit more work for a new protocol such as
cephfs.  Naturally we intend to do get that done, but would like to
know if it will be a blocker in getting the driver in tree.


This is not currently a requirement for any of the existing 3rd party 
drivers so it wouldn't be fair to enforce it on cephfs.


It *is* something we would like to require at some point, because just 
running the API tests don't really ensure that the driver isn't broken, 
but I'm trying to be sensitive to vendors' limited resources and to add 
CI requirements gradually. The fact that the current generic driver is 
unstable in the gate is a much more serious issue than the fact that 
some drivers don't pass scenario tests.



Many thanks,
John

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




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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Eugene Korekin]

Yes, I am aware that this is the expected behavior, at least from the 
developer point of view.


Still, some functionality to confine plugin actions within the 
environment where it is supposed to run would be an useful option, what 
do you think?



On 07.12.2015 20:19, Andrew Woodward wrote:
I'd have to say that this is expected behavior. I'm not sure what you 
would hope to prohibit when these kinds of things are necessary for 
the deployment. We also can't prohibit this from being done in a 
plugin, this is what the plugin verification is supposed to help 
combat. If you just go download a random puppet manifest // script // 
etc... from the internet, how do you ensure that it didn't install a 
root-kit.


On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin > wrote:


As far as I know this feature is planned for the next releases.

But I think the main problem is: it's not obvious that just by
installing a plugin, even without enabling the plugin in Fuel user
could break or somehow alter already existing environments.  It
could be done by malicious attacker who could compromise plugin or
just unintentionally with some bug in the plugin code.

Unfortunately, by installing some plugin a user jeopardizes his
existing environments. And I think we should at least document
these risks.


On 07.12.2015 19:52, Javeria Khan wrote:


My two cents. It would be useful to have a role that could
execute on the Fuel Master host itself rather than a container.

--
Javeria

On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" mailto:m...@romcheg.me>> wrote:

Alexey,

thank you for bringing this up. IMO discussing security
problems is better to be done in a special kind of Launchpad
bugs.

- romcheg


> 7 груд. 2015 р. о 17:36 Alexey Elagin mailto:aela...@mirantis.com>> написав(ла):
>
> Hello all,
>
> We have a security problem in Fuel 7.0. It's related to plugin
> development and allows to execute code in mcollective
docker container
> on Fuel master node. Any fuel plugin may contains a yaml
file with
> deployment tasks (tasks.yaml, deployment_tasks.yaml etc)
and there is
> an ability to run some code on node with role "master".
It's also
> possible to connect to any target node via ssh without a
password from
> within the container.
>
> As i understood, it was made to simplify some deployment
cases. I see
> some steps for resolving this situation:
> 1. Fuel team should disallow
> execution of any puppet manifests or bash code on nodes
with master
> role.
> 2. Append the Fuel documentation. Notify users about this
> security issue.
>
> What do you think about it? What deployment cases which require
> execution of code on role "master" do you know?
>
> --
> Best regards,
> Alexey
> Deployment Engineer
> Mirantis, Inc
> Cell: +7 (968) 880 2288 
> Skype: shikelbober
> Slack: aelagin
> mailto:aela...@mirantis.com 
>
>
>

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

>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


-- 
Eugene Korekin

Partner Enablement Team Deployment Engineer

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

--

Andrew Woodward

Mira

Re: [openstack-dev] [Manila] Tempest scenario tests vs. gate condition

[John Spray]

On Mon, Dec 7, 2015 at 6:14 PM, Ben Swartzlander  wrote:
> On 12/03/2015 06:38 AM, John Spray wrote:
>>
>> Hi,
>>
>> We're working towards getting the devstack/CI parts ready to test the
>> forthcoming ceph native driver, and have a question: will a driver be
>> accepted into the tree if it has CI for running the api/ tempest
>> tests, but not the scenario/ tempest tests?
>>
>> The context is that because the scenario tests require a client to
>> mount the shares, that's a bit more work for a new protocol such as
>> cephfs.  Naturally we intend to do get that done, but would like to
>> know if it will be a blocker in getting the driver in tree.
>
>
> This is not currently a requirement for any of the existing 3rd party
> drivers so it wouldn't be fair to enforce it on cephfs.
>
> It *is* something we would like to require at some point, because just
> running the API tests don't really ensure that the driver isn't broken, but
> I'm trying to be sensitive to vendors' limited resources and to add CI
> requirements gradually. The fact that the current generic driver is unstable
> in the gate is a much more serious issue than the fact that some drivers
> don't pass scenario tests.

Understood, thanks to you and Valeriy for the clarification.

John

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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Eugene Korekin]

Stas,

I fear that often even developer of a code cannot verify his own code 
completely, let alone some third-party validation teams. Does the 
ability to strictly limit plugin actions by the list of intended 
environments looks nonviable to you?



On 07.12.2015 20:38, Stanislaw Bogatkin wrote:
+1 to Andrew. Plugins created for run some code and plugin 
verification is the source of trust there.


On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward > wrote:


I'd have to say that this is expected behavior. I'm not sure what
you would hope to prohibit when these kinds of things are
necessary for the deployment. We also can't prohibit this from
being done in a plugin, this is what the plugin verification is
supposed to help combat. If you just go download a random puppet
manifest // script // etc... from the internet, how do you ensure
that it didn't install a root-kit.

On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin
mailto:ekore...@mirantis.com>> wrote:

As far as I know this feature is planned for the next releases.

But I think the main problem is: it's not obvious that just by
installing a plugin, even without enabling the plugin in Fuel
user could break or somehow alter already existing
environments.  It could be done by malicious attacker who
could compromise plugin or just unintentionally with some bug
in the plugin code.

Unfortunately, by installing some plugin a user jeopardizes
his existing environments. And I think we should at least
document these risks.


On 07.12.2015 19:52, Javeria Khan wrote:


My two cents. It would be useful to have a role that could
execute on the Fuel Master host itself rather than a container.

--
Javeria

On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" mailto:m...@romcheg.me>> wrote:

Alexey,

thank you for bringing this up. IMO discussing security
problems is better to be done in a special kind of
Launchpad bugs.

- romcheg


> 7 груд. 2015 р. о 17:36 Alexey Elagin
mailto:aela...@mirantis.com>>
написав(ла):
>
> Hello all,
>
> We have a security problem in Fuel 7.0. It's related to
plugin
> development and allows to execute code in mcollective
docker container
> on Fuel master node. Any fuel plugin may contains a
yaml file with
> deployment tasks (tasks.yaml, deployment_tasks.yaml
etc) and there is
> an ability to run some code on node with role "master".
It's also
> possible to connect to any target node via ssh without
a password from
> within the container.
>
> As i understood, it was made to simplify some
deployment cases. I see
> some steps for resolving this situation:
> 1. Fuel team should disallow
> execution of any puppet manifests or bash code on nodes
with master
> role.
> 2. Append the Fuel documentation. Notify users about this
> security issue.
>
> What do you think about it? What deployment cases which
require
> execution of code on role "master" do you know?
>
> --
> Best regards,
> Alexey
> Deployment Engineer
> Mirantis, Inc
> Cell: +7 (968) 880 2288 
> Skype: shikelbober
> Slack: aelagin
> mailto:aela...@mirantis.com 
>
>
>

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


>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)

Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

[Thomas Goirand]

On 12/07/2015 06:07 PM, Cory Benfield wrote:
> 
>> On 7 Dec 2015, at 16:10, Thomas Goirand  wrote:
>>
>> Cory,
>>
>> Thanks a lot for this patch.
>>
>> If I understand well, in Debian, I'd have to remove the:
>>
>> [options]
>> analytics_tracking_code = UA-17511903-1
>>
>> from the default theme.conf to make the GA code go away. Right? Would
>> there be a way so that I could set an environment variable instead of
>> patching the file, which is always a pain?
> 
> You don’t need to remove that, you set it in `html_theme_options` in the 
> conf.py for the relevant docs. That’s a fairly simple patch, but if the docs 
> theme people are open to having an environment variable we could set up the 
> default conf.py appropriately.
>
> NB: You’d want html_theme_options to be set to:
> 
> html_theme_options = {
> ‘analytics_tracking_code’: ‘'
> }

Ok, got you. :)

Though, if currently, I just have to patch openstackdocstheme (meaning,
a single patch), now, with what you're suggesting, I'd have to modify
each and every *user* of the theme, meaning I'd have to patch each and
every packages to have the correct conf.py file. That's unfortunately
not very practical.

The reason why I'd like an env var, is that I could simply modify
openstack-pkg-tools (which is included in every debian/rules) to set
that variable once and for all. For example, just adding in
openstack-pkt-tools's pkgos.make:

export OPENSTACKDOCSTHEME_SELF_CONTAINED=yes

would do the trick for all my packages.

Your thoughts?

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Adam Heczko]

For future Fuel versions we could/should develop kind of RBAC model for
accessing internal components.
I'm not sure if current nailgun/astute provides any capability like this.
Also plugins often interacts with operating system itself, which is another
area of concern.
IMO we could only rely on plugin certification here.
Not sure if certified plugins are signed actually / and if there is any
possibility to check signatures prior to (or during) plugin installation?

A.

On Mon, Dec 7, 2015 at 7:29 PM, Eugene Korekin 
wrote:

> Stas,
>
> I fear that often even developer of a code cannot verify his own code
> completely, let alone some third-party validation teams. Does the ability
> to strictly limit plugin actions by the list of intended environments looks
> nonviable to you?
>
>
>
> On 07.12.2015 20:38, Stanislaw Bogatkin wrote:
>
> +1 to Andrew. Plugins created for run some code and plugin verification is
> the source of trust there.
>
> On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward  wrote:
>
>> I'd have to say that this is expected behavior. I'm not sure what you
>> would hope to prohibit when these kinds of things are necessary for the
>> deployment. We also can't prohibit this from being done in a plugin, this
>> is what the plugin verification is supposed to help combat. If you just go
>> download a random puppet manifest // script // etc... from the internet,
>> how do you ensure that it didn't install a root-kit.
>>
>> On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin 
>> wrote:
>>
>>> As far as I know this feature is planned for the next releases.
>>>
>>> But I think the main problem is: it's not obvious that just by
>>> installing a plugin, even without enabling the plugin in Fuel user could
>>> break or somehow alter already existing environments.  It could be done by
>>> malicious attacker who could compromise plugin or just unintentionally with
>>> some bug in the plugin code.
>>>
>>> Unfortunately, by installing some plugin a user jeopardizes his existing
>>> environments. And I think we should at least document these risks.
>>>
>>>
>>> On 07.12.2015 19:52, Javeria Khan wrote:
>>>
>>> My two cents. It would be useful to have a role that could execute on
>>> the Fuel Master host itself rather than a container.
>>>
>>> --
>>> Javeria
>>> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" < 
>>> m...@romcheg.me> wrote:
>>>
 Alexey,

 thank you for bringing this up. IMO discussing security problems is
 better to be done in a special kind of Launchpad bugs.

 - romcheg


 > 7 груд. 2015 р. о 17:36 Alexey Elagin 
 написав(ла):
 >
 > Hello all,
 >
 > We have a security problem in Fuel 7.0. It's related to plugin
 > development and allows to execute code in mcollective docker container
 > on Fuel master node. Any fuel plugin may contains a yaml file with
 > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
 > an ability to run some code on node with role "master". It's also
 > possible to connect to any target node via ssh without a password from
 > within the container.
 >
 > As i understood, it was made to simplify some deployment cases. I see
 > some steps for resolving this situation:
 > 1. Fuel team should disallow
 > execution of any puppet manifests or bash code on nodes with master
 > role.
 > 2. Append the Fuel documentation. Notify users about this
 > security issue.
 >
 > What do you think about it? What deployment cases which require
 > execution of code on role "master" do you know?
 >
 > --
 > Best regards,
 > Alexey
 > Deployment Engineer
 > Mirantis, Inc
 > Cell: +7 (968) 880 2288 <%2B7%20%28968%29%20880%202288>
 > Skype: shikelbober
 > Slack: aelagin
 > mailto:aela...@mirantis.com
 >
 >
 >
 __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> --
>>> Eugene Korekin
>>> Partner Enablement Team Deployment Engineer
>>>
>>>
>>> __
>>> OpenStack Development Mail

Re: [openstack-dev] [heat] Rico Lin for heat-core

[Pavlo Shchelokovskyy]

+1 :)

On Mon, Dec 7, 2015, 17:12 Thomas Herve  wrote:

> On Mon, Dec 7, 2015 at 1:39 PM, Sergey Kraynev 
> wrote:
>
>>
>> Hi all.
>>
>> I'd like to nominate Rico Lin for heat-core. He did awesome job with
>> providing useful and valuable reviews. Also his contribution is really high
>> [1] .
>>
>> [1] http://stackalytics.com/report/contribution/heat-group/60
>>
>> Heat core-team, please vote with:
>>  +1 - if you agree
>>   -1 - if you disagree
>>
>>
> +1.
>
> --
> Thomas
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Rico Lin for heat-core

[Steve Baker]

On 08/12/15 01:39, Sergey Kraynev wrote:

Hi all.

I'd like to nominate Rico Lin for heat-core. He did awesome job with 
providing useful and valuable reviews. Also his contribution is really 
high [1] .


[1] http://stackalytics.com/report/contribution/heat-group/60

Heat core-team, please vote with:
 +1 - if you agree
  -1 - if you disagree


+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